phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sigurd Nes
Subject: Re: [Phpgroupware-developers] layers and db-calls in proposalbranch
Date: Sun, 11 Apr 2004 21:41:58 +0200
User-agent: Mozilla Thunderbird 0.5 (X11/20040208)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]