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

[Sigurd Nes]

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