[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Phpgroupware-developers] layers and db-calls in proposalbranch
From: |
Joseph Engo |
Subject: |
Re: [Phpgroupware-developers] layers and db-calls in proposalbranch |
Date: |
Mon, 12 Apr 2004 02:46:55 -0400 |
User-agent: |
Mozilla Thunderbird 0.5 (Windows/20040207) |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAejtd/AzmiD/o0voRArPZAKCK12+dt33GOxn7jcRdfeSf7C/o2wCcC/0f
MUHjtbhiCadHNVooWjf0pTA=
=54v6
-----END PGP SIGNATURE-----