Re: [Phpgroupware-developers] layers and db-calls in proposalbranch

[Chris Weiss]

since http limits the number of redirects you can do a redirect is not usualy
the best way.  Might be better, and even easier (in most cases), to have your
index kickstart the module you need instead of redirecting to it.  Certainly
would be faster and less load on the server since a redirect makes 2 http
connections instead of just the one requested.

Sigurd Nes (address@hidden) wrote:
>
> In HEAD there is a very useful function which I could not find in proposal
> $GLOBALS['phpgw']->redirect_link('/index.php',$start_page);
>
> It is desirable to have this ability because the $start_page within this
> app is set by the users preferences
>
> I was thinking the property.base.start could act as the 
> �index.php� in
> HEAD � the user�s preferences is picked up and he is redirected 
> to the
> submodule of his choice within the app.
>
> This would make the porting (for my part) from HEAD easy.
>
> Sigurd
>
> Joseph Engo wrote:
>  > I would also recommend making your "starting page" as
>  > property.base.start ... thats the first place it will always go by
>  > default.
>  >
>  > Another thing to keep in mind, header() calls should _never_ be made
>  > in the new API.  Prepare your output before hand, (in arrays if
>  > possiable, to make porting easier).  You can always change it if
>  > needed before its returned.
>  >
>  > I think its a good idea for us to start up a wiki doc explaining some
>  > basic steps developers should take now in order to make porting easier
>  > when the time comes.
>  >
>  > Sigurd Nes wrote:
>  >
>  > | I am givinig it a try with property from HEAD:
>  > |
>  > | I have moved the classes from /app/inc/ to /app/
>  > |
>  > | in the class.base.php (property_base) I do like this:
>  > |
>  > | currentapp='property';
>  > | $start_page='sid=cookie&op='.$currentapp.'.uilocation.index';
>  > | header('Location:
>  > | '.$GLOBALS['HTTP_SERVER_VARS']['PHP_SELF'].'?'.$start_page);
>  > |
>  > | When I hit my app icon - I get a warning from mozilla - telling me
>  > | that "Redirection limit for this URL exeeded. Unable to load the
>  > | requested page. This may be caused by cookies that are blocked"
>  > |
>  > | If I try to type the address by hand - which is:
>  > |
>  >
> /~sigurd/proposal/phpgroupware/index.php?sid=cookie&op=property.uilocation.index
>
>  >
>  > |
>  > |
>  > |
>  > | I get: WARNING! property_uilocation does not exist WARNING!
>  > | property.uilocation.index does not exist
>  > |
>  > | Do I have to register my classes somewhere?
>  > |
>  > | One other thing: I think it would be nice to be able to add the
>  > | xsl-templates as an array - as currently in HEAD
>  > |
>  > | Sigurd
>  > |
>  > |
>  > |
>  > | Dan Kuykendall wrote:
>  > |
>  > |> Sigurd Nes wrote:
>  > |>
>  > |>> Hi
>  > |>>
>  > |>> I see that the app note is beginning to take form
>  > |>
>  > |>
>  > |>
>  > |> Yep. Jengo is working on the notes app already.
>  > |>
>  > |>> 1) Are you moving away from the "ui","bo" and "so" - classes ?
>  > |>>
>  > |>> (I have 29 different ui-classes in the property app - and it
>  > |>> would be nice to be able to reuse the code...)
>  > |>
>  > |>
>  > |>
>  > |> In some sense we are moving away from the ui classes, since they
>  > |> are not really needed anymore. The main reason for the UI classes
>  > |>  in the current phpgw is to handle dealing with the phplib
>  > |> templates, and to generally generate the html. Since all of this
>  > |> logic can be handled by XSLT, there just isnt much need for it.
>  > |>
>  > |> However you are in no way prevented from having a UI class... I
>  > |> suppose it could be used to make sure the resulting XML is
>  > |> structure some specific way... I guess.
>  > |>
>  > |> Also, yesterday I added a bunch of support for handling apps that
>  > |>  generate their own output. Its part of the small compatibility
>  > |> layer that will sit on top of the new framework. Of course this
>  > |> is VERY discouraged because it means the app will not be
>  > |> compatibile with any other interface than the browser... but it
>  > |> should make porting a tad easier.
>  > |>
>  > |>> 2) I notice that the proposal branch has moved to adodb - will
>  > |>> I still be able to use this db-calls?
>  > |>> $GLOBALS['phpgw']->db->query()
>  > |>> $GLOBALS['phpgw']->db->limit_query()
>  > |>> $GLOBALS['phpgw']->db->next_record()
>  > |>> $GLOBALS['phpgw']->db->f('field_name')
>  > |>
>  > |>
>  > |>
>  > |> The db calls are a little diff. Let me take your example and show
>  > |>  you both phplib and adodb
>  > |>
>  > |> In phplib $sql = "SELECT * FROM sometable";
>  > |> $this->db->limit_query(5);
>  > |> $this->db->query($sql,__LINE__,__FILE__);
>  > |> if(!$this->db->num_rows()) {     echo $this->db->f('pref_value');
>  > |>  }
>  > |>
>  > |> Now in adodb
>  > |>
>  > |> $sql = "SELECT * FROM sometable"; $dbresult =
>  > |> $GLOBALS['phpgw']->db->Execute($sql, 5); while (!$dbresult->EOF)
>  > |> { echo $dbresult['fields']['pref_value']; $dbresult->MoveNext();
>  > |> }
>  > |>
>  > |> A few notes about all this 1) Notice in the query is named
>  > |> Execute. There is also a query function which is an alias and
>  > |> will work. 2) In the execute the 2nd param is the limit method.
>  > |> 3) In adodb it returns the reference object. So you can do nested
>  > |>  queries without any of the problems phplib has with that. 4) In
>  > |> adodb by default you are in the first record right away. This is
>  > |> why the MoveNext is called inside the loop, otherwise you would
>  > |> skip the first record.
>  > |>
>  > |> Porting to adodb was a bit of a hassle, but it wasnt hard. It was
>  > |>  just tedious. For more details about adodb visit their website
>  > |> http://php.weblogs.com/ADODB
>  > |>
>  > |> Dan
>  > |>
>  > |
>  > |
>  > | _______________________________________________
>  > | Phpgroupware-developers mailing list
>  > | address@hidden
>  > | http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>  >
>  >
>
>
>
>
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>