This early version is fully workable (though there are still other features we need to add) and is meant for hardcore POG developers to play with.
Please send us your feedback. It will help us a lot. Soon, we'll add some documentation to this thread about what has changed, what to look for, things we're still planning to improve etc.
Thanks for your patience and support, The POG Team.
First thoughts based on 5 minutes reading the code that it generates...
(1) Generated class code uses calls to POG_Base::Unescape and POG_Base::Escape rather than $this->Unescape and $this->Escape which means I can't alter the standard behaviour of these functions in my subclasses
(2) What part of Get() and GetList() could not be generalised and put in the base class (reducing the configuration of subclasses almost to the definition of the pog_attribute_type array since the same applies to the Save and Delete routines)?
(3) A POG_Base routine along the lines of FillFieldFromDBResult( $fieldName, $result) and GetFieldForSQLStatement($fieldName) would give the user some hooks to do per-field Escape/Unescape logic. Alternatively, changing the signature of Escape/Unescape (and using $this-> as in 1 above) would give the same possibility.
Later,
Andy
------------- Yada, yada, yada...
Roslin Institute is a company limited by guarantee, registered in Scotland (registered number SC157100) and a Scottish Charity (registered number SC023592). Our registered office is at Roslin, Midlothian, EH25 9PS. VAT registration number 847380013.
The information contained in this e-mail (including any attachments) is confidential and is intended for the use of the addressee only. The opinions expressed within this e-mail (including any attachments) are the opinions of the sender and do not necessarily constitute those of Roslin Institute (Edinburgh) ("the Institute") unless specifically stated by a sender who is duly authorised to do so on behalf of the Institute.
> -----Original Message----- > From: Php-Object-Generator@googlegroups.com > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel > Sent: 19 April 2007 03:43 > To: Php Object Generator > Subject: [Php-Object-Generator:1038] POG 3.0 alpha available
> We've just made a commit of the alpha version of 3.0 to the > SVN repository.
> This early version is fully workable (though there are still > other features we need to add) and is meant for hardcore POG > developers to play with.
> Please send us your feedback. It will help us a lot. Soon, > we'll add some documentation to this thread about what has > changed, what to look for, things we're still planning to improve etc.
> Thanks for your patience and support, > The POG Team.
Very well done joel, pog 3 seems very interesting :) I will surely play with the plug-ins interface and see what I can get out of it.
Regards,
Paris Paraskeva Managing Director M.E. & E. United Worx Ltd 33, Apostolou Pavlou Avenue, Office 103, 8046 Paphos, Cyprus Tel.: +357 26220707, +357 26221313, Mob.: +357 99575501 Fax.: +357 26221002 pa...@unitedworx.com www.unitedworx.com
The information contained in this email message(and any attachments) is legally privileged and confidential information intended only for the use of the addressee(s) listed on this email. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution or copy of this email is strictly prohibited. If you have received this email in error, please notify us by telephone or email on the contact details shown on the end of this email. Thank you.
[mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel Sent: Thursday, April 19, 2007 5:43 AM To: Php Object Generator Subject: [Php-Object-Generator:1038] POG 3.0 alpha available
We've just made a commit of the alpha version of 3.0 to the SVN repository.
This early version is fully workable (though there are still other features we need to add) and is meant for hardcore POG developers to play with.
Please send us your feedback. It will help us a lot. Soon, we'll add some documentation to this thread about what has changed, what to look for, things we're still planning to improve etc.
Thanks for your patience and support, The POG Team.
This was one of the main focus for this release. 1. Minimize the # of calls to the database by entire result sets for GetList, GetChildrenList, GetSiblingList 2. Smarter SQL queries. POG now lets the database handle the data decoding for queries that were inefficient such as the ones that involved sorting, limits.
Database encoding is, by default, turned off. POG also provides a base64 plugin by default. To enable data encoding, the user needs to run setup, go to the plugins tab, and enable the base64 plugin there. Enabling the plugin will, in effect, install a base64 custom function into the database. Then the user can set encoding to 1 in the configuration. When POG sees db_encoding = 1, it assumes that the custom base64 function is installed and uses queries that use this custom function.
To shave off a few more seconds on very large datasets, the generator hardcodes things within GetList and Get instead of trying to perform those 'calculations' at run time. Note, Andy, I will comment on your points regarding this in my next post.
What we still need to work on in terms of optimization is to create a plugin that will allow loading of children/siblings in 1 database call. Currently, if you load a list of objects, you still need to loop through the objects to load the children/sibling separately. This will help in scenarios such as reporting where the developer needs to load large amounts of data. Since GetList(), GetChildrenList() and GetSiblingList() are all done in 1 call now, the performance index is linear w.r.t the # of children being loaded. Even without this plugin that we're working on, performance should not be an issue anymore.
2) The next big thing in 3.0 is the plugin architecture. You'll now notice a plugins folder that get generated by default. As well, we provide a default base64 plugin (see 1) above). Plugins are usually application side functions, i.e. they extend the functionality of all objects by providing a specific function. For example, a Search plugin provides a search function to all objects. Once this search plugin is installed, the developer can do $object->Search(args) and it do its job.
To make the lives of plugin developers easy, we provide the POG_Base object that any plugin can extend. In the POG_Base we intend to provide generic functions that will help abstract common code.
Note: in Alpha, we havent yet hooked the objects to pog_base. we intend to do this soon. We also are not using the functions in POG_Base within the generated code (for e.g. generalizing Get() and GetList() as mentioned by Andy above) because there is a performance penalty (albeit a small one) when doing so. Plugins, however, should use these base functions as they are not 'generated'.
We are also working on standardizing the database class (note that even PDO code will now use a database class) so that plugins are easily compatible with all 3 php versions we support: php 4, php5 and php 5+pdo.
Plugins can also be Setup-side plugins (as is the base64 plugin we provide). i.e they do not provide any function to the object. Instead, their purpose is to facilitate manipulation of the database. Of course, plugins can also have both (setup side and application side)
- session_start has been removed from configuration
- GetList now allows comparison on column names to support comparisons between columns and the IN operator. For example if you want to get the list of all objects where 1 attribute > than the other, use the mysql quote around the value such as (Note the ` character around createdon)
array(" lastUpdatedOn", ">", "`createdon`")
- standardized the API for getlist, getchildrenlist and getsibling list: they all return everything if no arguments are passed.
Mostly, what we're working on for BETA are:
- churn out some plugins and improve pog_base, class.database.php so that plugin development is easy and intuitive. - see if we can refactor some code into pog_base without affecting performance - add some other default functions to each object such as GetCount(), etc. - clean up - new design for the generator website.
Regards, The POG Team.
On Apr 19, 2:59 am, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> First thoughts based on 5 minutes reading the code that it generates...
> (1) Generated class code uses calls to POG_Base::Unescape and > POG_Base::Escape rather than $this->Unescape and $this->Escape which > means I can't alter the standard behaviour of these functions in my > subclasses
> (2) What part of Get() and GetList() could not be generalised and put in > the base class (reducing the configuration of subclasses almost to the > definition of the pog_attribute_type array since the same applies to the > Save and Delete routines)?
> (3) A POG_Base routine along the lines of FillFieldFromDBResult( > $fieldName, $result) and GetFieldForSQLStatement($fieldName) would give > the user some hooks to do per-field Escape/Unescape logic. > Alternatively, changing the signature of Escape/Unescape (and using > $this-> as in 1 above) would give the same possibility.
> Later,
> Andy
> ------------- > Yada, yada, yada...
> Roslin Institute is a company limited by guarantee, registered in > Scotland (registered number SC157100) and a Scottish Charity (registered > number SC023592). Our registered office is at Roslin, Midlothian, EH25 > 9PS. VAT registration number 847380013.
> The information contained in this e-mail (including any attachments) is > confidential and is intended for the use of the addressee only. The > opinions expressed within this e-mail (including any attachments) are > the opinions of the sender and do not necessarily constitute those of > Roslin Institute (Edinburgh) ("the Institute") unless specifically > stated by a sender who is duly authorised to do so on behalf of the > Institute.
> > -----Original Message----- > > From: Php-Object-Generator@googlegroups.com > > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel > > Sent: 19 April 2007 03:43 > > To: Php Object Generator > > Subject: [Php-Object-Generator:1038] POG 3.0 alpha available
> > We've just made a commit of the alpha version of 3.0 to the > > SVN repository.
> > This early version is fully workable (though there are still > > other features we need to add) and is meant for hardcore POG > > developers to play with.
> > Please send us your feedback. It will help us a lot. Soon, > > we'll add some documentation to this thread about what has > > changed, what to look for, things we're still planning to improve etc.
> > Thanks for your patience and support, > > The POG Team.
1) Right, I understand, and i think you're right, we can change it to $this->escape in the objects. As mentioned in my post above, we haven't yet hooked up the generated objects with POG_Base. We'll hook them up before beta.
2) For performance reasons, Get and GetList were made as explicit as possible. i.e. no lookups at all during runtime. (let the generator do what a generator does best). However, we still intend to create those functions that will allow internal lookups for the purpose of plugins.
3) Agreed, there are already some functions there such as Fetch objects which will take the result of a select SQL statement and transform the result into an array of objects. This, arguably was to be used both in Get() and GetList() but (and it does work correctly), but i think we'll leave the usage to plugins since we want the core methods to be as fast as possible. Nothing has been set in stone though..
regards, Joel
On Apr 19, 10:10 am, Joel <joel...@gmail.com> wrote:
> This was one of the main focus for this release. > 1. Minimize the # of calls to the database by entire result sets for > GetList, GetChildrenList, GetSiblingList > 2. Smarter SQL queries. POG now lets the database handle the data > decoding for queries that were inefficient such as the ones that > involved sorting, limits.
> Database encoding is, by default, turned off. POG also provides a > base64 plugin by default. To enable data encoding, the user needs to > run setup, go to the plugins tab, and enable the base64 plugin there. > Enabling the plugin will, in effect, install a base64 custom function > into the database. Then the user can set encoding to 1 in the > configuration. When POG sees db_encoding = 1, it assumes that the > custom base64 function is installed and uses queries that use this > custom function.
> To shave off a few more seconds on very large datasets, the generator > hardcodes things within GetList and Get instead of trying to perform > those 'calculations' at run time. Note, Andy, I will comment on your > points regarding this in my next post.
> What we still need to work on in terms of optimization is to create a > plugin that will allow loading of children/siblings in 1 database > call. Currently, if you load a list of objects, you still need to loop > through the objects to load the children/sibling separately. This will > help in scenarios such as reporting where the developer needs to load > large amounts of data. Since GetList(), GetChildrenList() and > GetSiblingList() are all done in 1 call now, the performance index is > linear w.r.t the # of children being loaded. Even without this plugin > that we're working on, performance should not be an issue anymore.
> 2) The next big thing in 3.0 is the plugin architecture. > You'll now notice a plugins folder that get generated by default. As > well, we provide a default base64 plugin (see 1) above). Plugins are > usually application side functions, i.e. they extend the functionality > of all objects by providing a specific function. For example, a Search > plugin provides a search function to all objects. Once this search > plugin is installed, the developer can do $object->Search(args) and it > do its job.
> To make the lives of plugin developers easy, we provide the POG_Base > object that any plugin can extend. In the POG_Base we intend to > provide generic functions that will help abstract common code.
> Note: > in Alpha, we havent yet hooked the objects to pog_base. we intend to > do this soon. We also are not using the functions in POG_Base within > the generated code (for e.g. generalizing Get() and GetList() as > mentioned by Andy above) because there is a performance penalty > (albeit a small one) when doing so. Plugins, however, should use these > base functions as they are not 'generated'.
> We are also working on standardizing the database class (note that > even PDO code will now use a database class) so that plugins are > easily compatible with all 3 php versions we support: php 4, php5 and > php 5+pdo.
> Plugins can also be Setup-side plugins (as is the base64 plugin we > provide). i.e they do not provide any function to the object. Instead, > their purpose is to facilitate manipulation of the database. Of > course, plugins can also have both (setup side and application side)
> - session_start has been removed from configuration
> - GetList now allows comparison on column names to support comparisons > between columns and the IN operator. For example if you want to get > the list of all objects where 1 attribute > than the other, use the > mysql quote around the value such as (Note the ` character around > createdon)
> array(" lastUpdatedOn", ">", "`createdon`")
> - standardized the API for getlist, getchildrenlist and getsibling > list: they all return everything if no arguments are passed.
> Mostly, what we're working on for BETA are:
> - churn out some plugins and improve pog_base, class.database.php so > that plugin development is easy and intuitive. > - see if we can refactor some code into pog_base without affecting > performance > - add some other default functions to each object such as GetCount(), > etc. > - clean up > - new design for the generator website.
> Regards, > The POG Team.
> On Apr 19, 2:59 am, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> > Joel,
> > Good to get a look at it. Thanks.
> > First thoughts based on 5 minutes reading the code that it generates...
> > (1) Generated class code uses calls to POG_Base::Unescape and > > POG_Base::Escape rather than $this->Unescape and $this->Escape which > > means I can't alter the standard behaviour of these functions in my > > subclasses
> > (2) What part of Get() and GetList() could not be generalised and put in > > the base class (reducing the configuration of subclasses almost to the > > definition of the pog_attribute_type array since the same applies to the > > Save and Delete routines)?
> > (3) A POG_Base routine along the lines of FillFieldFromDBResult( > > $fieldName, $result) and GetFieldForSQLStatement($fieldName) would give > > the user some hooks to do per-field Escape/Unescape logic. > > Alternatively, changing the signature of Escape/Unescape (and using > > $this-> as in 1 above) would give the same possibility.
> > Later,
> > Andy
> > ------------- > > Yada, yada, yada...
> > Roslin Institute is a company limited by guarantee, registered in > > Scotland (registered number SC157100) and a Scottish Charity (registered > > number SC023592). Our registered office is at Roslin, Midlothian, EH25 > > 9PS. VAT registration number 847380013.
> > The information contained in this e-mail (including any attachments) is > > confidential and is intended for the use of the addressee only. The > > opinions expressed within this e-mail (including any attachments) are > > the opinions of the sender and do not necessarily constitute those of > > Roslin Institute (Edinburgh) ("the Institute") unless specifically > > stated by a sender who is duly authorised to do so on behalf of the > > Institute.
> > > -----Original Message----- > > > From: Php-Object-Generator@googlegroups.com > > > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel > > > Sent: 19 April 2007 03:43 > > > To: Php Object Generator > > > Subject: [Php-Object-Generator:1038] POG 3.0 alpha available
> > > We've just made a commit of the alpha version of 3.0 to the > > > SVN repository.
> > > This early version is fully workable (though there are still > > > other features we need to add) and is meant for hardcore POG > > > developers to play with.
> > > Please send us your feedback. It will help us a lot. Soon, > > > we'll add some documentation to this thread about what has > > > changed, what to look for, things we're still planning to improve etc.
> > > Thanks for your patience and support, > > > The POG Team.
Just reading through the code right now, the following comes to mind.
1) Does __call() work on php4 objects without jiggery-pokery? Reading the php.net docs, the implication is that we need to call 'overload()' on the POG objects before __call() gets registered. I can't see where this is being done, nor do I know if this needs to be done on every object or doing it just on the base class will work.
2) The Base64 plugin feels clunky to me. All the instructions in the configuration file seem like an awful rigmarole to make users go through. I recognise that having the encoding in the database should be quicker, but at what price in complexity?
I will have another look at it tomorrow.
Later,
Andy
------------- Yada, yada, yada...
Roslin Institute is a company limited by guarantee, registered in Scotland (registered number SC157100) and a Scottish Charity (registered number SC023592). Our registered office is at Roslin, Midlothian, EH25 9PS. VAT registration number 847380013.
The information contained in this e-mail (including any attachments) is confidential and is intended for the use of the addressee only. The opinions expressed within this e-mail (including any attachments) are the opinions of the sender and do not necessarily constitute those of Roslin Institute (Edinburgh) ("the Institute") unless specifically stated by a sender who is duly authorised to do so on behalf of the Institute.
> -----Original Message----- > From: Php-Object-Generator@googlegroups.com > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel > Sent: 19 April 2007 17:22 > To: Php Object Generator > Subject: [Php-Object-Generator:1043] Re: POG 3.0 alpha available
> re:Andy
> 1) Right, I understand, and i think you're right, we can > change it to $this->escape in the objects. As mentioned in my > post above, we haven't yet hooked up the generated objects > with POG_Base. We'll hook them up before beta.
> 2) For performance reasons, Get and GetList were made as > explicit as possible. i.e. no lookups at all during runtime. > (let the generator do what a generator does best). However, > we still intend to create those functions that will allow > internal lookups for the purpose of plugins.
> 3) Agreed, there are already some functions there such as > Fetch objects which will take the result of a select SQL > statement and transform the result into an array of objects. > This, arguably was to be used both in Get() and GetList() but > (and it does work correctly), but i think we'll leave the > usage to plugins since we want the core methods to be as fast > as possible. Nothing has been set in stone though..
> regards, > Joel
> On Apr 19, 10:10 am, Joel <joel...@gmail.com> wrote: > > Things to look for in 3.0 alpha.
> > 1) Optimization strategy used:
> > This was one of the main focus for this release. > > 1. Minimize the # of calls to the database by entire > result sets for > > GetList, GetChildrenList, GetSiblingList 2. Smarter SQL > queries. POG > > now lets the database handle the data decoding for queries > that were > > inefficient such as the ones that involved sorting, limits.
> > Database encoding is, by default, turned off. POG also provides a > > base64 plugin by default. To enable data encoding, the user > needs to > > run setup, go to the plugins tab, and enable the base64 > plugin there. > > Enabling the plugin will, in effect, install a base64 > custom function > > into the database. Then the user can set encoding to 1 in the > > configuration. When POG sees db_encoding = 1, it assumes that the > > custom base64 function is installed and uses queries that use this > > custom function.
> > To shave off a few more seconds on very large datasets, the > generator > > hardcodes things within GetList and Get instead of trying > to perform > > those 'calculations' at run time. Note, Andy, I will > comment on your > > points regarding this in my next post.
> > What we still need to work on in terms of optimization is > to create a > > plugin that will allow loading of children/siblings in 1 database > > call. Currently, if you load a list of objects, you still > need to loop > > through the objects to load the children/sibling > separately. This will > > help in scenarios such as reporting where the developer > needs to load > > large amounts of data. Since GetList(), GetChildrenList() and > > GetSiblingList() are all done in 1 call now, the > performance index is > > linear w.r.t the # of children being loaded. Even without > this plugin > > that we're working on, performance should not be an issue anymore.
> > 2) The next big thing in 3.0 is the plugin architecture. > > You'll now notice a plugins folder that get generated by > default. As > > well, we provide a default base64 plugin (see 1) above). > Plugins are > > usually application side functions, i.e. they extend the > functionality > > of all objects by providing a specific function. For > example, a Search > > plugin provides a search function to all objects. Once this search > > plugin is installed, the developer can do > $object->Search(args) and it > > do its job.
> > To make the lives of plugin developers easy, we provide the > POG_Base > > object that any plugin can extend. In the POG_Base we intend to > > provide generic functions that will help abstract common code.
> > Note: > > in Alpha, we havent yet hooked the objects to pog_base. we > intend to > > do this soon. We also are not using the functions in > POG_Base within > > the generated code (for e.g. generalizing Get() and GetList() as > > mentioned by Andy above) because there is a performance penalty > > (albeit a small one) when doing so. Plugins, however, > should use these > > base functions as they are not 'generated'.
> > We are also working on standardizing the database class (note that > > even PDO code will now use a database class) so that plugins are > > easily compatible with all 3 php versions we support: php > 4, php5 and > > php 5+pdo.
> > Plugins can also be Setup-side plugins (as is the base64 plugin we > > provide). i.e they do not provide any function to the > object. Instead, > > their purpose is to facilitate manipulation of the database. Of > > course, plugins can also have both (setup side and application side)
> > - session_start has been removed from configuration
> > - GetList now allows comparison on column names to support > comparisons > > between columns and the IN operator. For example if you want to get > > the list of all objects where 1 attribute > than the other, use the > > mysql quote around the value such as (Note the ` character around > > createdon)
> > array(" lastUpdatedOn", ">", "`createdon`")
> > - standardized the API for getlist, getchildrenlist and getsibling > > list: they all return everything if no arguments are passed.
> > Mostly, what we're working on for BETA are:
> > - churn out some plugins and improve pog_base, > class.database.php so > > that plugin development is easy and intuitive. > > - see if we can refactor some code into pog_base without affecting > > performance > > - add some other default functions to each object such as > GetCount(), > > etc. > > - clean up > > - new design for the generator website.
> > Regards, > > The POG Team.
> > On Apr 19, 2:59 am, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> > > Joel,
> > > Good to get a look at it. Thanks.
> > > First thoughts based on 5 minutes reading the code that > it generates...
> > > (1) Generated class code uses calls to POG_Base::Unescape and > > > POG_Base::Escape rather than $this->Unescape and > $this->Escape which > > > means I can't alter the standard behaviour of these > functions in my > > > subclasses
> > > (2) What part of Get() and GetList() could not be generalised and > > > put in the base class (reducing the configuration of subclasses > > > almost to the definition of the pog_attribute_type array > since the > > > same applies to the Save and Delete routines)?
> > > (3) A POG_Base routine along the lines of FillFieldFromDBResult( > > > $fieldName, $result) and > GetFieldForSQLStatement($fieldName) would > > > give the user some hooks to do per-field Escape/Unescape logic. > > > Alternatively, changing the signature of Escape/Unescape > (and using > > > $this-> as in 1 above) would give the same possibility.
> > > Later,
> > > Andy
> > > ------------- > > > Yada, yada, yada...
> > > Roslin Institute is a company limited by guarantee, registered in > > > Scotland (registered number SC157100) and a Scottish Charity > > > (registered number SC023592). Our registered office is at Roslin, > > > Midlothian, EH25 9PS. VAT registration number 847380013.
> > > The information contained in this e-mail (including any > attachments) is > > > confidential and is intended for the use of the addressee > only. The > > > opinions expressed within this e-mail (including any attachments) > > > are the opinions of the sender and do not necessarily constitute > > > those of Roslin Institute (Edinburgh) ("the Institute") unless > > > specifically stated by a sender who is duly authorised to > do so on > > > behalf of the Institute.
> > > > -----Original Message----- > > > > From: Php-Object-Generator@googlegroups.com > > > > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel > > > > Sent: 19 April 2007 03:43 > > > > To: Php Object
1) Correct. the developer will need to overload the objects or we can try to do it.. haven't tried the pog_base option you outlined yet... plugins won't be as 'intuitive' in php4 as in php5+ but that's just a limitation of the language itself.
2). The explanation is clunky, and i'll try to simplify it, but honestly, it boils down to clicking a few buttons and the developers gets automatic encoding/decoding. i don't know of any other library or even method of making it simpler... And by default, encoding will be turned off because encoding will truly only be needed in a production enviroment or at certain points in the development.
The gains performance-wise are simply too much to not push the decode/ encode into the db. having personally used pog in a large application really pushed the old pog to the limit...
this can be further discussed though, and any other suggestions for simplication will be appreciated...
joel
On Apr 19, 3:34 pm, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> Just reading through the code right now, the following comes to mind.
> 1) Does __call() work on php4 objects without jiggery-pokery? Reading > the php.net docs, the implication is that we need to call 'overload()' > on the POG objects before __call() gets registered. I can't see where > this is being done, nor do I know if this needs to be done on every > object or doing it just on the base class will work.
> 2) The Base64 plugin feels clunky to me. All the instructions in the > configuration file seem like an awful rigmarole to make users go > through. I recognise that having the encoding in the database should be > quicker, but at what price in complexity?
> I will have another look at it tomorrow.
> Later,
> Andy
> ------------- > Yada, yada, yada...
> Roslin Institute is a company limited by guarantee, registered in > Scotland (registered number SC157100) and a Scottish Charity (registered > number SC023592). Our registered office is at Roslin, Midlothian, EH25 > 9PS. VAT registration number 847380013.
> The information contained in this e-mail (including any attachments) is > confidential and is intended for the use of the addressee only. The > opinions expressed within this e-mail (including any attachments) are > the opinions of the sender and do not necessarily constitute those of > Roslin Institute (Edinburgh) ("the Institute") unless specifically > stated by a sender who is duly authorised to do so on behalf of the > Institute.
> > -----Original Message----- > > From: Php-Object-Generator@googlegroups.com > > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel > > Sent: 19 April 2007 17:22 > > To: Php Object Generator > > Subject: [Php-Object-Generator:1043] Re: POG 3.0 alpha available
> > re:Andy
> > 1) Right, I understand, and i think you're right, we can > > change it to $this->escape in the objects. As mentioned in my > > post above, we haven't yet hooked up the generated objects > > with POG_Base. We'll hook them up before beta.
> > 2) For performance reasons, Get and GetList were made as > > explicit as possible. i.e. no lookups at all during runtime. > > (let the generator do what a generator does best). However, > > we still intend to create those functions that will allow > > internal lookups for the purpose of plugins.
> > 3) Agreed, there are already some functions there such as > > Fetch objects which will take the result of a select SQL > > statement and transform the result into an array of objects. > > This, arguably was to be used both in Get() and GetList() but > > (and it does work correctly), but i think we'll leave the > > usage to plugins since we want the core methods to be as fast > > as possible. Nothing has been set in stone though..
> > regards, > > Joel
> > On Apr 19, 10:10 am, Joel <joel...@gmail.com> wrote: > > > Things to look for in 3.0 alpha.
> > > 1) Optimization strategy used:
> > > This was one of the main focus for this release. > > > 1. Minimize the # of calls to the database by entire > > result sets for > > > GetList, GetChildrenList, GetSiblingList 2. Smarter SQL > > queries. POG > > > now lets the database handle the data decoding for queries > > that were > > > inefficient such as the ones that involved sorting, limits.
> > > Database encoding is, by default, turned off. POG also provides a > > > base64 plugin by default. To enable data encoding, the user > > needs to > > > run setup, go to the plugins tab, and enable the base64 > > plugin there. > > > Enabling the plugin will, in effect, install a base64 > > custom function > > > into the database. Then the user can set encoding to 1 in the > > > configuration. When POG sees db_encoding = 1, it assumes that the > > > custom base64 function is installed and uses queries that use this > > > custom function.
> > > To shave off a few more seconds on very large datasets, the > > generator > > > hardcodes things within GetList and Get instead of trying > > to perform > > > those 'calculations' at run time. Note, Andy, I will > > comment on your > > > points regarding this in my next post.
> > > What we still need to work on in terms of optimization is > > to create a > > > plugin that will allow loading of children/siblings in 1 database > > > call. Currently, if you load a list of objects, you still > > need to loop > > > through the objects to load the children/sibling > > separately. This will > > > help in scenarios such as reporting where the developer > > needs to load > > > large amounts of data. Since GetList(), GetChildrenList() and > > > GetSiblingList() are all done in 1 call now, the > > performance index is > > > linear w.r.t the # of children being loaded. Even without > > this plugin > > > that we're working on, performance should not be an issue anymore.
> > > 2) The next big thing in 3.0 is the plugin architecture. > > > You'll now notice a plugins folder that get generated by > > default. As > > > well, we provide a default base64 plugin (see 1) above). > > Plugins are > > > usually application side functions, i.e. they extend the > > functionality > > > of all objects by providing a specific function. For > > example, a Search > > > plugin provides a search function to all objects. Once this search > > > plugin is installed, the developer can do > > $object->Search(args) and it > > > do its job.
> > > To make the lives of plugin developers easy, we provide the > > POG_Base > > > object that any plugin can extend. In the POG_Base we intend to > > > provide generic functions that will help abstract common code.
> > > Note: > > > in Alpha, we havent yet hooked the objects to pog_base. we > > intend to > > > do this soon. We also are not using the functions in > > POG_Base within > > > the generated code (for e.g. generalizing Get() and GetList() as > > > mentioned by Andy above) because there is a performance penalty > > > (albeit a small one) when doing so. Plugins, however, > > should use these > > > base functions as they are not 'generated'.
> > > We are also working on standardizing the database class (note that > > > even PDO code will now use a database class) so that plugins are > > > easily compatible with all 3 php versions we support: php > > 4, php5 and > > > php 5+pdo.
> > > Plugins can also be Setup-side plugins (as is the base64 plugin we > > > provide). i.e they do not provide any function to the > > object. Instead, > > > their purpose is to facilitate manipulation of the database. Of > > > course, plugins can also have both (setup side and application side)
> > > Other smaller changes > > > - Delete() now has 2 flags when relations are involved : $deep and > > > $across. See this for more > > details:http://groups.google.com/group/Php-Object-Generator/br > owse_thread/thr...
> > > - session_start has been removed from configuration
> > > - GetList now allows comparison on column names to support > > comparisons > > > between columns and the IN operator. For example if you want to get > > > the list of all objects where 1 attribute > than the other, use the > > > mysql quote around the value such as (Note the ` character around > > > createdon)
> > > array(" lastUpdatedOn", ">", "`createdon`")
> > > - standardized the API for getlist, getchildrenlist and getsibling > > > list: they all return everything if no arguments are passed.
> > > Mostly, what we're working on for BETA are:
> > > - churn out some plugins and improve pog_base, > > class.database.php so > > > that plugin development is easy and intuitive. > > > - see if we can refactor some code into pog_base without affecting > > > performance > > > - add some other default functions to each object such as > > GetCount(), > > > etc. > > > - clean up > > > - new design for the generator website.
> > > Regards, > > > The POG Team.
> > > On Apr 19, 2:59 am, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> > > > Joel,
> > > > Good to get a look at it. Thanks.
> > > > First thoughts based on 5 minutes reading the code that > > it generates...
> > > > (1) Generated class code uses calls to POG_Base::Unescape and > > > > POG_Base::Escape rather than $this->Unescape and > > $this->Escape which > > > > means I can't alter the standard behaviour of these > > functions in my > > > > subclasses
> > > > (2) What part of Get() and GetList() could not be generalised and > > > > put in the base class (reducing the configuration of subclasses > > > > almost to the definition of the pog_attribute_type array > > since the > > > > same applies to the Save and Delete routines)?
> > > > (3) A POG_Base routine along the lines of FillFieldFromDBResult( > > > > $fieldName, $result) and > > GetFieldForSQLStatement($fieldName) would > > > > give the user some hooks to do per-field Escape/Unescape
#1 for php4 we could also create a function object-
>CallPlugin('pluginName', argv) instead of relying on overload, as
Mark suggested in the beginning....
#2 we could also make the base64 plugin edit the configuration file so that there's only one control point: the plugins tab. this would also get rid of the instructions too...
comments.?
On Apr 19, 3:45 pm, Joel <joel...@gmail.com> wrote:
> 1) Correct. the developer will need to overload the objects or we can > try to do it.. haven't tried the pog_base option you outlined yet... > plugins won't be as 'intuitive' in php4 as in php5+ but that's just a > limitation of the language itself.
> 2). The explanation is clunky, and i'll try to simplify it, but > honestly, it boils down to clicking a few buttons and the developers > gets automatic encoding/decoding. i don't know of any other library or > even method of making it simpler... And by default, encoding will be > turned off because encoding will truly only be needed in a production > enviroment or at certain points in the development.
> The gains performance-wise are simply too much to not push the decode/ > encode into the db. having personally used pog in a large application > really pushed the old pog to the limit...
> this can be further discussed though, and any other suggestions for > simplication will be appreciated...
> joel
> On Apr 19, 3:34 pm, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> > Joel,
> > Just reading through the code right now, the following comes to mind.
> > 1) Does __call() work on php4 objects without jiggery-pokery? Reading > > the php.net docs, the implication is that we need to call 'overload()' > > on the POG objects before __call() gets registered. I can't see where > > this is being done, nor do I know if this needs to be done on every > > object or doing it just on the base class will work.
> > 2) The Base64 plugin feels clunky to me. All the instructions in the > > configuration file seem like an awful rigmarole to make users go > > through. I recognise that having the encoding in the database should be > > quicker, but at what price in complexity?
> > I will have another look at it tomorrow.
> > Later,
> > Andy
> > ------------- > > Yada, yada, yada...
> > Roslin Institute is a company limited by guarantee, registered in > > Scotland (registered number SC157100) and a Scottish Charity (registered > > number SC023592). Our registered office is at Roslin, Midlothian, EH25 > > 9PS. VAT registration number 847380013.
> > The information contained in this e-mail (including any attachments) is > > confidential and is intended for the use of the addressee only. The > > opinions expressed within this e-mail (including any attachments) are > > the opinions of the sender and do not necessarily constitute those of > > Roslin Institute (Edinburgh) ("the Institute") unless specifically > > stated by a sender who is duly authorised to do so on behalf of the > > Institute.
> > > -----Original Message----- > > > From: Php-Object-Generator@googlegroups.com > > > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel > > > Sent: 19 April 2007 17:22 > > > To: Php Object Generator > > > Subject: [Php-Object-Generator:1043] Re: POG 3.0 alpha available
> > > re:Andy
> > > 1) Right, I understand, and i think you're right, we can > > > change it to $this->escape in the objects. As mentioned in my > > > post above, we haven't yet hooked up the generated objects > > > with POG_Base. We'll hook them up before beta.
> > > 2) For performance reasons, Get and GetList were made as > > > explicit as possible. i.e. no lookups at all during runtime. > > > (let the generator do what a generator does best). However, > > > we still intend to create those functions that will allow > > > internal lookups for the purpose of plugins.
> > > 3) Agreed, there are already some functions there such as > > > Fetch objects which will take the result of a select SQL > > > statement and transform the result into an array of objects. > > > This, arguably was to be used both in Get() and GetList() but > > > (and it does work correctly), but i think we'll leave the > > > usage to plugins since we want the core methods to be as fast > > > as possible. Nothing has been set in stone though..
> > > regards, > > > Joel
> > > On Apr 19, 10:10 am, Joel <joel...@gmail.com> wrote: > > > > Things to look for in 3.0 alpha.
> > > > 1) Optimization strategy used:
> > > > This was one of the main focus for this release. > > > > 1. Minimize the # of calls to the database by entire > > > result sets for > > > > GetList, GetChildrenList, GetSiblingList 2. Smarter SQL > > > queries. POG > > > > now lets the database handle the data decoding for queries > > > that were > > > > inefficient such as the ones that involved sorting, limits.
> > > > Database encoding is, by default, turned off. POG also provides a > > > > base64 plugin by default. To enable data encoding, the user > > > needs to > > > > run setup, go to the plugins tab, and enable the base64 > > > plugin there. > > > > Enabling the plugin will, in effect, install a base64 > > > custom function > > > > into the database. Then the user can set encoding to 1 in the > > > > configuration. When POG sees db_encoding = 1, it assumes that the > > > > custom base64 function is installed and uses queries that use this > > > > custom function.
> > > > To shave off a few more seconds on very large datasets, the > > > generator > > > > hardcodes things within GetList and Get instead of trying > > > to perform > > > > those 'calculations' at run time. Note, Andy, I will > > > comment on your > > > > points regarding this in my next post.
> > > > What we still need to work on in terms of optimization is > > > to create a > > > > plugin that will allow loading of children/siblings in 1 database > > > > call. Currently, if you load a list of objects, you still > > > need to loop > > > > through the objects to load the children/sibling > > > separately. This will > > > > help in scenarios such as reporting where the developer > > > needs to load > > > > large amounts of data. Since GetList(), GetChildrenList() and > > > > GetSiblingList() are all done in 1 call now, the > > > performance index is > > > > linear w.r.t the # of children being loaded. Even without > > > this plugin > > > > that we're working on, performance should not be an issue anymore.
> > > > 2) The next big thing in 3.0 is the plugin architecture. > > > > You'll now notice a plugins folder that get generated by > > > default. As > > > > well, we provide a default base64 plugin (see 1) above). > > > Plugins are > > > > usually application side functions, i.e. they extend the > > > functionality > > > > of all objects by providing a specific function. For > > > example, a Search > > > > plugin provides a search function to all objects. Once this search > > > > plugin is installed, the developer can do > > > $object->Search(args) and it > > > > do its job.
> > > > To make the lives of plugin developers easy, we provide the > > > POG_Base > > > > object that any plugin can extend. In the POG_Base we intend to > > > > provide generic functions that will help abstract common code.
> > > > Note: > > > > in Alpha, we havent yet hooked the objects to pog_base. we > > > intend to > > > > do this soon. We also are not using the functions in > > > POG_Base within > > > > the generated code (for e.g. generalizing Get() and GetList() as > > > > mentioned by Andy above) because there is a performance penalty > > > > (albeit a small one) when doing so. Plugins, however, > > > should use these > > > > base functions as they are not 'generated'.
> > > > We are also working on standardizing the database class (note that > > > > even PDO code will now use a database class) so that plugins are > > > > easily compatible with all 3 php versions we support: php > > > 4, php5 and > > > > php 5+pdo.
> > > > Plugins can also be Setup-side plugins (as is the base64 plugin we > > > > provide). i.e they do not provide any function to the > > > object. Instead, > > > > their purpose is to facilitate manipulation of the database. Of > > > > course, plugins can also have both (setup side and application side)
> > > > Other smaller changes > > > > - Delete() now has 2 flags when relations are involved : $deep and > > > > $across. See this for more > > > details:http://groups.google.com/group/Php-Object-Generator/br > > owse_thread/thr...
> > > > - session_start has been removed from configuration
> > > > - GetList now allows comparison on column names to support > > > comparisons > > > > between columns and the IN operator. For example if you want to get > > > > the list of all objects where 1 attribute > than the other, use the > > > > mysql quote around the value such as (Note the ` character around > > > > createdon)
> > > > - standardized the API for getlist, getchildrenlist and getsibling > > > > list: they all return everything if no arguments are passed.
> > > > Mostly, what we're working on for BETA are:
> > > > - churn out some plugins and improve pog_base, > > > class.database.php so > > > > that plugin development is easy and intuitive. > > > > - see if we can refactor some code into pog_base without affecting > > > > performance > > > > - add some other default functions to each object such as > > > GetCount(), > > > > etc. > > > > - clean up > > > > - new design for the generator website.
> > > > Regards, > > > > The POG Team.
> > > > On Apr 19, 2:59 am, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> > > > > Joel,
> > > > > Good to get a look at it. Thanks.
> > > > > First thoughts based on 5 minutes reading the code that
> #1 for php4 we could also create a function object->CallPlugin('pluginName', argv) instead of relying on overload, as
> Mark suggested in the beginning....
> #2 we could also make the base64 plugin edit the configuration file so > that there's only one control point: the plugins tab. this would also > get rid of the instructions too...
> comments.?
> On Apr 19, 3:45 pm, Joel <joel...@gmail.com> wrote:
> > 1) Correct. the developer will need to overload the objects or we can > > try to do it.. haven't tried the pog_base option you outlined yet... > > plugins won't be as 'intuitive' in php4 as in php5+ but that's just a > > limitation of the language itself.
> > 2). The explanation is clunky, and i'll try to simplify it, but > > honestly, it boils down to clicking a few buttons and the developers > > gets automatic encoding/decoding. i don't know of any other library or > > even method of making it simpler... And by default, encoding will be > > turned off because encoding will truly only be needed in a production > > enviroment or at certain points in the development.
> > The gains performance-wise are simply too much to not push the decode/ > > encode into the db. having personally used pog in a large application > > really pushed the old pog to the limit...
> > this can be further discussed though, and any other suggestions for > > simplication will be appreciated...
> > joel
> > On Apr 19, 3:34 pm, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> > > Joel,
> > > Just reading through the code right now, the following comes to mind.
> > > 1) Does __call() work on php4 objects without jiggery-pokery? Reading > > > the php.net docs, the implication is that we need to call 'overload()' > > > on the POG objects before __call() gets registered. I can't see where > > > this is being done, nor do I know if this needs to be done on every > > > object or doing it just on the base class will work.
> > > 2) The Base64 plugin feels clunky to me. All the instructions in the > > > configuration file seem like an awful rigmarole to make users go > > > through. I recognise that having the encoding in the database should be > > > quicker, but at what price in complexity?
> > > I will have another look at it tomorrow.
> > > Later,
> > > Andy
> > > ------------- > > > Yada, yada, yada...
> > > Roslin Institute is a company limited by guarantee, registered in > > > Scotland (registered number SC157100) and a Scottish Charity (registered > > > number SC023592). Our registered office is at Roslin, Midlothian, EH25 > > > 9PS. VAT registration number 847380013.
> > > The information contained in this e-mail (including any attachments) is > > > confidential and is intended for the use of the addressee only. The > > > opinions expressed within this e-mail (including any attachments) are > > > the opinions of the sender and do not necessarily constitute those of > > > Roslin Institute (Edinburgh) ("the Institute") unless specifically > > > stated by a sender who is duly authorised to do so on behalf of the > > > Institute.
> > > > -----Original Message----- > > > > From: Php-Object-Generator@googlegroups.com > > > > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel > > > > Sent: 19 April 2007 17:22 > > > > To: Php Object Generator > > > > Subject: [Php-Object-Generator:1043] Re: POG 3.0 alpha available
> > > > re:Andy
> > > > 1) Right, I understand, and i think you're right, we can > > > > change it to $this->escape in the objects. As mentioned in my > > > > post above, we haven't yet hooked up the generated objects > > > > with POG_Base. We'll hook them up before beta.
> > > > 2) For performance reasons, Get and GetList were made as > > > > explicit as possible. i.e. no lookups at all during runtime. > > > > (let the generator do what a generator does best). However, > > > > we still intend to create those functions that will allow > > > > internal lookups for the purpose of plugins.
> > > > 3) Agreed, there are already some functions there such as > > > > Fetch objects which will take the result of a select SQL > > > > statement and transform the result into an array of objects. > > > > This, arguably was to be used both in Get() and GetList() but > > > > (and it does work correctly), but i think we'll leave the > > > > usage to plugins since we want the core methods to be as fast > > > > as possible. Nothing has been set in stone though..
> > > > regards, > > > > Joel
> > > > On Apr 19, 10:10 am, Joel <joel...@gmail.com> wrote: > > > > > Things to look for in 3.0 alpha.
> > > > > 1) Optimization strategy used:
> > > > > This was one of the main focus for this release. > > > > > 1. Minimize the # of calls to the database by entire > > > > result sets for > > > > > GetList, GetChildrenList, GetSiblingList 2. Smarter SQL > > > > queries. POG > > > > > now lets the database handle the data decoding for queries > > > > that were > > > > > inefficient such as the ones that involved sorting, limits.
> > > > > Database encoding is, by default, turned off. POG also provides a > > > > > base64 plugin by default. To enable data encoding, the user > > > > needs to > > > > > run setup, go to the plugins tab, and enable the base64 > > > > plugin there. > > > > > Enabling the plugin will, in effect, install a base64 > > > > custom function > > > > > into the database. Then the user can set encoding to 1 in the > > > > > configuration. When POG sees db_encoding = 1, it assumes that the > > > > > custom base64 function is installed and uses queries that use this > > > > > custom function.
> > > > > To shave off a few more seconds on very large datasets, the > > > > generator > > > > > hardcodes things within GetList and Get instead of trying > > > > to perform > > > > > those 'calculations' at run time. Note, Andy, I will > > > > comment on your > > > > > points regarding this in my next post.
> > > > > What we still need to work on in terms of optimization is > > > > to create a > > > > > plugin that will allow loading of children/siblings in 1 database > > > > > call. Currently, if you load a list of objects, you still > > > > need to loop > > > > > through the objects to load the children/sibling > > > > separately. This will > > > > > help in scenarios such as reporting where the developer > > > > needs to load > > > > > large amounts of data. Since GetList(), GetChildrenList() and > > > > > GetSiblingList() are all done in 1 call now, the > > > > performance index is > > > > > linear w.r.t the # of children being loaded. Even without > > > > this plugin > > > > > that we're working on, performance should not be an issue anymore.
> > > > > 2) The next big thing in 3.0 is the plugin architecture. > > > > > You'll now notice a plugins folder that get generated by > > > > default. As > > > > > well, we provide a default base64 plugin (see 1) above). > > > > Plugins are > > > > > usually application side functions, i.e. they extend the > > > > functionality > > > > > of all objects by providing a specific function. For > > > > example, a Search > > > > > plugin provides a search function to all objects. Once this search > > > > > plugin is installed, the developer can do > > > > $object->Search(args) and it > > > > > do its job.
> > > > > To make the lives of plugin developers easy, we provide the > > > > POG_Base > > > > > object that any plugin can extend. In the POG_Base we intend to > > > > > provide generic functions that will help abstract common code.
> > > > > Note: > > > > > in Alpha, we havent yet hooked the objects to pog_base. we > > > > intend to > > > > > do this soon. We also are not using the functions in > > > > POG_Base within > > > > > the generated code (for e.g. generalizing Get() and GetList() as > > > > > mentioned by Andy above) because there is a performance penalty > > > > > (albeit a small one) when doing so. Plugins, however, > > > > should use these > > > > > base functions as they are not 'generated'.
> > > > > We are also working on standardizing the database class (note that > > > > > even PDO code will now use a database class) so that plugins are > > > > > easily compatible with all 3 php versions we support: php > > > > 4, php5 and > > > > > php 5+pdo.
> > > > > Plugins can also be Setup-side plugins (as is the base64 plugin we > > > > > provide). i.e they do not provide any function to the > > > > object. Instead, > > > > > their purpose is to facilitate manipulation of the database. Of > > > > > course, plugins can also have both (setup side and application side)
> > > > > Other smaller changes > > > > > - Delete() now has 2 flags when relations are involved : $deep and > > > > > $across. See this for more > > > > details:http://groups.google.com/group/Php-Object-Generator/br > > > owse_thread/thr...
> > > > > - session_start has been removed from configuration
> > > > > - GetList now allows comparison on column names to support > > > > comparisons > > > > > between columns and the IN operator. For example if you want to get > > > > > the list of all objects where 1 attribute > than the other, use the > > > > > mysql quote around the value such as (Note the ` character around > > > > > createdon)
Alpha 2 has been commited to SVN and refreshed on the beta website:
This update includes:
<fix> standardized db wrappers across php versions so that one plugin can fit all php version <fix> cleaned up objects <fix> object overloading in php4 fixed and tested <fix> updated test projects <fix> base64 plugin now fits all 3 php versions <fix> pog objects now extend pog_base
regards,
On Apr 20, 3:37 am, Joel <joel...@gmail.com> wrote:
> Tested and confirmed that #1 overloading in php4 should be ok and will > be handled by us. The user won't have to do anything different than > php5+
> On Apr 19, 3:51 pm, Joel <joel...@gmail.com> wrote:
> > #1 for php4 we could also create a function object->CallPlugin('pluginName', argv) instead of relying on overload, as
> > Mark suggested in the beginning....
> > #2 we could also make the base64 plugin edit the configuration file so > > that there's only one control point: the plugins tab. this would also > > get rid of the instructions too...
> > comments.?
> > On Apr 19, 3:45 pm, Joel <joel...@gmail.com> wrote:
> > > 1) Correct. the developer will need to overload the objects or we can > > > try to do it.. haven't tried the pog_base option you outlined yet... > > > plugins won't be as 'intuitive' in php4 as in php5+ but that's just a > > > limitation of the language itself.
> > > 2). The explanation is clunky, and i'll try to simplify it, but > > > honestly, it boils down to clicking a few buttons and the developers > > > gets automatic encoding/decoding. i don't know of any other library or > > > even method of making it simpler... And by default, encoding will be > > > turned off because encoding will truly only be needed in a production > > > enviroment or at certain points in the development.
> > > The gains performance-wise are simply too much to not push the decode/ > > > encode into the db. having personally used pog in a large application > > > really pushed the old pog to the limit...
> > > this can be further discussed though, and any other suggestions for > > > simplication will be appreciated...
> > > joel
> > > On Apr 19, 3:34 pm, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> > > > Joel,
> > > > Just reading through the code right now, the following comes to mind.
> > > > 1) Does __call() work on php4 objects without jiggery-pokery? Reading > > > > the php.net docs, the implication is that we need to call 'overload()' > > > > on the POG objects before __call() gets registered. I can't see where > > > > this is being done, nor do I know if this needs to be done on every > > > > object or doing it just on the base class will work.
> > > > 2) The Base64 plugin feels clunky to me. All the instructions in the > > > > configuration file seem like an awful rigmarole to make users go > > > > through. I recognise that having the encoding in the database should be > > > > quicker, but at what price in complexity?
> > > > I will have another look at it tomorrow.
> > > > Later,
> > > > Andy
> > > > ------------- > > > > Yada, yada, yada...
> > > > Roslin Institute is a company limited by guarantee, registered in > > > > Scotland (registered number SC157100) and a Scottish Charity (registered > > > > number SC023592). Our registered office is at Roslin, Midlothian, EH25 > > > > 9PS. VAT registration number 847380013.
> > > > The information contained in this e-mail (including any attachments) is > > > > confidential and is intended for the use of the addressee only. The > > > > opinions expressed within this e-mail (including any attachments) are > > > > the opinions of the sender and do not necessarily constitute those of > > > > Roslin Institute (Edinburgh) ("the Institute") unless specifically > > > > stated by a sender who is duly authorised to do so on behalf of the > > > > Institute.
> > > > > -----Original Message----- > > > > > From: Php-Object-Generator@googlegroups.com > > > > > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel > > > > > Sent: 19 April 2007 17:22 > > > > > To: Php Object Generator > > > > > Subject: [Php-Object-Generator:1043] Re: POG 3.0 alpha available
> > > > > re:Andy
> > > > > 1) Right, I understand, and i think you're right, we can > > > > > change it to $this->escape in the objects. As mentioned in my > > > > > post above, we haven't yet hooked up the generated objects > > > > > with POG_Base. We'll hook them up before beta.
> > > > > 2) For performance reasons, Get and GetList were made as > > > > > explicit as possible. i.e. no lookups at all during runtime. > > > > > (let the generator do what a generator does best). However, > > > > > we still intend to create those functions that will allow > > > > > internal lookups for the purpose of plugins.
> > > > > 3) Agreed, there are already some functions there such as > > > > > Fetch objects which will take the result of a select SQL > > > > > statement and transform the result into an array of objects. > > > > > This, arguably was to be used both in Get() and GetList() but > > > > > (and it does work correctly), but i think we'll leave the > > > > > usage to plugins since we want the core methods to be as fast > > > > > as possible. Nothing has been set in stone though..
> > > > > regards, > > > > > Joel
> > > > > On Apr 19, 10:10 am, Joel <joel...@gmail.com> wrote: > > > > > > Things to look for in 3.0 alpha.
> > > > > > 1) Optimization strategy used:
> > > > > > This was one of the main focus for this release. > > > > > > 1. Minimize the # of calls to the database by entire > > > > > result sets for > > > > > > GetList, GetChildrenList, GetSiblingList 2. Smarter SQL > > > > > queries. POG > > > > > > now lets the database handle the data decoding for queries > > > > > that were > > > > > > inefficient such as the ones that involved sorting, limits.
> > > > > > Database encoding is, by default, turned off. POG also provides a > > > > > > base64 plugin by default. To enable data encoding, the user > > > > > needs to > > > > > > run setup, go to the plugins tab, and enable the base64 > > > > > plugin there. > > > > > > Enabling the plugin will, in effect, install a base64 > > > > > custom function > > > > > > into the database. Then the user can set encoding to 1 in the > > > > > > configuration. When POG sees db_encoding = 1, it assumes that the > > > > > > custom base64 function is installed and uses queries that use this > > > > > > custom function.
> > > > > > To shave off a few more seconds on very large datasets, the > > > > > generator > > > > > > hardcodes things within GetList and Get instead of trying > > > > > to perform > > > > > > those 'calculations' at run time. Note, Andy, I will > > > > > comment on your > > > > > > points regarding this in my next post.
> > > > > > What we still need to work on in terms of optimization is > > > > > to create a > > > > > > plugin that will allow loading of children/siblings in 1 database > > > > > > call. Currently, if you load a list of objects, you still > > > > > need to loop > > > > > > through the objects to load the children/sibling > > > > > separately. This will > > > > > > help in scenarios such as reporting where the developer > > > > > needs to load > > > > > > large amounts of data. Since GetList(), GetChildrenList() and > > > > > > GetSiblingList() are all done in 1 call now, the > > > > > performance index is > > > > > > linear w.r.t the # of children being loaded. Even without > > > > > this plugin > > > > > > that we're working on, performance should not be an issue anymore.
> > > > > > 2) The next big thing in 3.0 is the plugin architecture. > > > > > > You'll now notice a plugins folder that get generated by > > > > > default. As > > > > > > well, we provide a default base64 plugin (see 1) above). > > > > > Plugins are > > > > > > usually application side functions, i.e. they extend the > > > > > functionality > > > > > > of all objects by providing a specific function. For > > > > > example, a Search > > > > > > plugin provides a search function to all objects. Once this search > > > > > > plugin is installed, the developer can do > > > > > $object->Search(args) and it > > > > > > do its job.
> > > > > > To make the lives of plugin developers easy, we provide the > > > > > POG_Base > > > > > > object that any plugin can extend. In the POG_Base we intend to > > > > > > provide generic functions that will help abstract common code.
> > > > > > Note: > > > > > > in Alpha, we havent yet hooked the objects to pog_base. we > > > > > intend to > > > > > > do this soon. We also are not using the functions in > > > > > POG_Base within > > > > > > the generated code (for e.g. generalizing Get() and GetList() as > > > > > > mentioned by Andy above) because there is a performance penalty > > > > > > (albeit a small one) when doing so. Plugins, however, > > > > > should use these > > > > > > base functions as they are not 'generated'.
> > > > > > We are also working on standardizing the database class (note that > > > > > > even PDO code will now use a database class) so that plugins are > > > > > > easily compatible with all 3 php versions we support: php > > > > > 4, php5 and > > > > > > php 5+pdo.
> > > > > > Plugins can also be Setup-side plugins (as is the base64 plugin we > > > > > > provide). i.e they do not provide any function to the > > > > > object. Instead, > > > > > > their purpose is to facilitate manipulation of the database. Of > > > > > > course, plugins can also have both (setup side and application side)
> > > > > > Other smaller changes > > > > > > - Delete() now has 2 flags when relations are involved : $deep and > > > > > > $across. See this for more > > > > > details:http://groups.google.com/group/Php-Object-Generator/br
> 2). The explanation is clunky, and i'll try to simplify it, > but honestly, it boils down to clicking a few buttons and the > developers gets automatic encoding/decoding. i don't know of > any other library or even method of making it simpler... And > by default, encoding will be turned off because encoding will > truly only be needed in a production enviroment or at certain > points in the development.
> The gains performance-wise are simply too much to not push > the decode/ encode into the db. having personally used pog in > a large application really pushed the old pog to the limit...
> this can be further discussed though, and any other > suggestions for simplication will be appreciated...
More thinking out loud.
There are actually two issues here, now I think hard about it.
A) to encode or not to encode
B) to encode in php or in the database engine
*I* would like (A) to (ultimately) be configurable at the field level, rather than at the system level. i.e. I would like to be able to specify that field X of object Y is encoded but field A is not.
The ability to encode in the database is a property of the 'database' object, is it not, rather than the pog object? So should we be thinking about how to push that 'flag' into the database object too?
Streaming on from that, I can imagine a system that offers different types of encode/decode and chooses the correct place to do the transformation depending on capability.
Later,
Andy
------------- Yada, yada, yada...
Roslin Institute is a company limited by guarantee, registered in Scotland (registered number SC157100) and a Scottish Charity (registered number SC023592). Our registered office is at Roslin, Midlothian, EH25 9PS. VAT registration number 847380013.
The information contained in this e-mail (including any attachments) is confidential and is intended for the use of the addressee only. The opinions expressed within this e-mail (including any attachments) are the opinions of the sender and do not necessarily constitute those of Roslin Institute (Edinburgh) ("the Institute") unless specifically stated by a sender who is duly authorised to do so on behalf of the Institute.
agreed; whatever has been implemented so far was merely an attempt to do what pog 2x was doing, but faster, and lay the foundation for an architecture that's more extensible.
The feature request to encode a specific field, as you mentioned, has not been solved (and the base64 plugin is not meant for this) .. and i now see where you're coming from...
the base64 plugin is for the use case where you'd want to encode everything since it eases programming. (user does not have to be careful about characters etc).
However, the request to encode specific field(s) is a separate issue, IMHO and it does raise the questions you mentioned above, and this is what i think:
- encoding arbitrary fields using arbitrary encoding/decoding algorithm is not a trivial problem to solve, especially if we still want performance, searching of the encoded data, and ease of use. Attempting to add this functionality to the POG Core would have a huge cost in terms of complexity and ease of use.
But i can still totally see that feature being implemented as a plugin. To specify the fields to be encoded (and pushing these flags to the db as you mentioned) can easily be done on the setup side of a plugin. Then, the special saving and loading is done through the application side of the same plugin.
I'm gonna get some rest and we'll see if what i just talked about makes sense tomorrow.. ;)
regards, joel
On 4/20/07, andy law (RI) <andy....@bbsrc.ac.uk> wrote:
> > 2). The explanation is clunky, and i'll try to simplify it, > > but honestly, it boils down to clicking a few buttons and the > > developers gets automatic encoding/decoding. i don't know of > > any other library or even method of making it simpler... And > > by default, encoding will be turned off because encoding will > > truly only be needed in a production enviroment or at certain > > points in the development.
> > The gains performance-wise are simply too much to not push > > the decode/ encode into the db. having personally used pog in > > a large application really pushed the old pog to the limit...
> > this can be further discussed though, and any other > > suggestions for simplication will be appreciated...
> More thinking out loud.
> There are actually two issues here, now I think hard about it.
> A) to encode or not to encode
> B) to encode in php or in the database engine
> *I* would like (A) to (ultimately) be configurable at the field level, > rather than at the system level. i.e. I would like to be able to specify > that field X of object Y is encoded but field A is not.
> The ability to encode in the database is a property of the 'database' > object, is it not, rather than the pog object? So should we be thinking > about how to push that 'flag' into the database object too?
> Streaming on from that, I can imagine a system that offers different > types of encode/decode and chooses the correct place to do the > transformation depending on capability.
> Later,
> Andy
> ------------- > Yada, yada, yada...
> Roslin Institute is a company limited by guarantee, registered in > Scotland (registered number SC157100) and a Scottish Charity (registered > number SC023592). Our registered office is at Roslin, Midlothian, EH25 > 9PS. VAT registration number 847380013.
> The information contained in this e-mail (including any attachments) is > confidential and is intended for the use of the addressee only. The > opinions expressed within this e-mail (including any attachments) are > the opinions of the sender and do not necessarily constitute those of > Roslin Institute (Edinburgh) ("the Institute") unless specifically > stated by a sender who is duly authorised to do so on behalf of the > Institute.
Some more rambling thoughts that occurred to me over the weekend, fuelled by a combination of tiredness, coffee and (bizzarrely) Champ Car racing on the telly.
The ability to base 64 encode/decode in the database is fundamental and should be part of the POG setup. I think it is distracting and confusing to have this as a plug-in. In addition, I think (as I said last week) that the 'db_encoding' preference and the 'db can encode' ability are two separate things.
I keep coming back to the per-field issue whenever I write code. The pog_attribute_type array is limiting in this respect as it has a complex, variable-length array embedded in it, with no simple way to inject other attributes alongside it. My gut instinct is screaming at me that this array should be altered and exposed as the *central* core of extensibility.
The benefit of that (as I see it) is that I can now insert other attributes alongside the _pog_dbattributes.
For example...
function setFieldAttribute( $fieldName, $attributeName, $attributeValue) { if (($fieldName) && ($attributeName)) { $this->pog_attribute_type[$fieldName][$attributeName] = $attributeValue; }
}
function getFieldAttribute( $fieldName, $attributeName) { $retVal = NULL; if (($fieldName) && ($attributeName)) { $retVal = $this->pog_attribute_type[$fieldName][$attributeName]; } return $retVal;
}
So I can define all manner of keyed parameters (required => true/false, acceptablePattern => <<regexp>>) etc and have a standard way of storing/retrieving them.
For ease of setting up extended attributes in subclasses, there could be a well-defined $pog_extra_attributes array that the standard constructor picked up and merged with the pog_attribute_type array.
Running on further form that, I wonder if there is then mileage in storing pre-canned snippets of SQL on a field-by-field basis within the atribute array which might then further speed up GetList() operations (since hash-based lookups are generally faster than if/then logic operations).
And now, back to what passes for *real* work :o{
Later,
Andy
------------- Yada, yada, yada...
Roslin Institute is a company limited by guarantee, registered in Scotland (registered number SC157100) and a Scottish Charity (registered number SC023592). Our registered office is at Roslin, Midlothian, EH25 9PS. VAT registration number 847380013.
The information contained in this e-mail (including any attachments) is confidential and is intended for the use of the addressee only. The opinions expressed within this e-mail (including any attachments) are the opinions of the sender and do not necessarily constitute those of Roslin Institute (Edinburgh) ("the Institute") unless specifically stated by a sender who is duly authorised to do so on behalf of the Institute.
> -----Original Message----- > From: Php-Object-Generator@googlegroups.com > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel Wan > Sent: 20 April 2007 12:26 > To: Php-Object-Generator@googlegroups.com > Subject: [Php-Object-Generator:1050] Re: POG 3.0 alpha available
> Hey Andy ;),
> agreed; whatever has been implemented so far was merely an > attempt to do what pog 2x was doing, but faster, and lay the > foundation for an architecture that's more extensible.
> The feature request to encode a specific field, as you > mentioned, has not been solved (and the base64 plugin is not > meant for this) .. and i now see where you're coming from...
> the base64 plugin is for the use case where you'd want to > encode everything since it eases programming. (user does not > have to be careful about characters etc).
> However, the request to encode specific field(s) is a > separate issue, IMHO and it does raise the questions you > mentioned above, and this is what i think:
> - encoding arbitrary fields using arbitrary encoding/decoding > algorithm is not a trivial problem to solve, especially if we > still want performance, searching of the encoded data, and > ease of use. Attempting to add this functionality to the POG > Core would have a huge cost in terms of complexity and ease of use.
> But i can still totally see that feature being implemented as > a plugin. To specify the fields to be encoded (and pushing > these flags to the db as you mentioned) can easily be done on > the setup side of a plugin. Then, the special saving and > loading is done through the application side of the same plugin.
> I'm gonna get some rest and we'll see if what i just talked > about makes sense tomorrow.. ;)
> regards, > joel
> On 4/20/07, andy law (RI) <andy....@bbsrc.ac.uk> wrote:
> Joel,
> > 2). The explanation is clunky, and i'll try to simplify it, > > but honestly, it boils down to clicking a few buttons and the > > developers gets automatic encoding/decoding. i don't know of > > any other library or even method of making it simpler... And > > by default, encoding will be turned off because encoding will > > truly only be needed in a production enviroment or at certain > > points in the development.
> > The gains performance-wise are simply too much to not push > > the decode/ encode into the db. having personally used pog in > > a large application really pushed the old pog to the limit...
> > this can be further discussed though, and any other > > suggestions for simplication will be appreciated...
> More thinking out loud.
> There are actually two issues here, now I think hard about it.
> A) to encode or not to encode
> B) to encode in php or in the database engine
> *I* would like (A) to (ultimately) be configurable at > the field level, > rather than at the system level. i.e. I would like to > be able to specify > that field X of object Y is encoded but field A is not.
> The ability to encode in the database is a property of > the 'database' > object, is it not, rather than the pog object? So > should we be thinking > about how to push that 'flag' into the database object too?
> Streaming on from that, I can imagine a system that > offers different > types of encode/decode and chooses the correct place to do the > transformation depending on capability.
> Later,
> Andy
> ------------- > Yada, yada, yada...
> Roslin Institute is a company limited by guarantee, > registered in > Scotland (registered number SC157100) and a Scottish > Charity (registered > number SC023592). Our registered office is at Roslin, > Midlothian, EH25 > 9PS. VAT registration number 847380013.
> The information contained in this e-mail (including any > attachments) is > confidential and is intended for the use of the > addressee only. The > opinions expressed within this e-mail (including any > attachments) are > the opinions of the sender and do not necessarily > constitute those of > Roslin Institute (Edinburgh) ("the Institute") unless > specifically > stated by a sender who is duly authorised to do so on > behalf of the > Institute.
i agree with your suggestions re: extending pog_attribute_type, making it more customizable and also creating some base function that allows easier manipulation. we'll make some changes for alpha 3 regarding this and you can then provide some more feedback. I do appreciate these suggestions as they're extremely useful IMHO.
i do not fully agree with having to remove base64 as a plugin. It should be looked at as a 'default' plugin which is why it is included automatically in the package. it does have some hooks that no other plugin will have (for e.g if the user has db_encoding = true and the base64 function is not installed, setup will stop and give the user a warning). the reason behind making base64 as a plugin v.s full hidden integration within setup is, we wanted to eat our own dogfood and show how plugins can be used. Moreover, we have an extensible platform, why not use it ourselves...
I do agree, however, that there could be some workflow improvements, such as maybe discerning between plugins we provide and plugins that are provided by third parties... So, i do agree that it can be confusing the first time.
This may be a bad example, but if you look at something like Firefox, it consumes some plugins out-of-the-box such as their "talkback addon" and another one i can't remember. The user is free to remove it, in which case ffox won't send crash results to the ffox servers. Likewise, if the user decides to get rid of the base64 plugin, there's no issue. the only consequence is that pog will not be able to encode/ decode data... but it'll still work ok.
regards, joel
On Apr 23, 4:05 am, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> Some more rambling thoughts that occurred to me over the weekend, > fuelled by a combination of tiredness, coffee and (bizzarrely) Champ Car > racing on the telly.
> The ability to base 64 encode/decode in the database is fundamental and > should be part of the POG setup. I think it is distracting and confusing > to have this as a plug-in. In addition, I think (as I said last week) > that the 'db_encoding' preference and the 'db can encode' ability are > two separate things.
> I keep coming back to the per-field issue whenever I write code. The > pog_attribute_type array is limiting in this respect as it has a > complex, variable-length array embedded in it, with no simple way to > inject other attributes alongside it. My gut instinct is screaming at me > that this array should be altered and exposed as the *central* core of > extensibility.
> So I can define all manner of keyed parameters (required => true/false, > acceptablePattern => <<regexp>>) etc and have a standard way of > storing/retrieving them.
> For ease of setting up extended attributes in subclasses, there could be > a well-defined $pog_extra_attributes array that the standard constructor > picked up and merged with the pog_attribute_type array.
> Running on further form that, I wonder if there is then mileage in > storing pre-canned snippets of SQL on a field-by-field basis within the > atribute array which might then further speed up GetList() operations > (since hash-based lookups are generally faster than if/then logic > operations).
> And now, back to what passes for *real* work :o{
> Later,
> Andy
> ------------- > Yada, yada, yada...
> Roslin Institute is a company limited by guarantee, registered in > Scotland (registered number SC157100) and a Scottish Charity (registered > number SC023592). Our registered office is at Roslin, Midlothian, EH25 > 9PS. VAT registration number 847380013.
> The information contained in this e-mail (including any attachments) is > confidential and is intended for the use of the addressee only. The > opinions expressed within this e-mail (including any attachments) are > the opinions of the sender and do not necessarily constitute those of > Roslin Institute (Edinburgh) ("the Institute") unless specifically > stated by a sender who is duly authorised to do so on behalf of the > Institute.
> > -----Original Message----- > > From: Php-Object-Generator@googlegroups.com > > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel Wan > > Sent: 20 April 2007 12:26 > > To: Php-Object-Generator@googlegroups.com > > Subject: [Php-Object-Generator:1050] Re: POG 3.0 alpha available
> > Hey Andy ;),
> > agreed; whatever has been implemented so far was merely an > > attempt to do what pog 2x was doing, but faster, and lay the > > foundation for an architecture that's more extensible.
> > The feature request to encode a specific field, as you > > mentioned, has not been solved (and the base64 plugin is not > > meant for this) .. and i now see where you're coming from...
> > the base64 plugin is for the use case where you'd want to > > encode everything since it eases programming. (user does not > > have to be careful about characters etc).
> > However, the request to encode specific field(s) is a > > separate issue, IMHO and it does raise the questions you > > mentioned above, and this is what i think:
> > - encoding arbitrary fields using arbitrary encoding/decoding > > algorithm is not a trivial problem to solve, especially if we > > still want performance, searching of the encoded data, and > > ease of use. Attempting to add this functionality to the POG > > Core would have a huge cost in terms of complexity and ease of use.
> > But i can still totally see that feature being implemented as > > a plugin. To specify the fields to be encoded (and pushing > > these flags to the db as you mentioned) can easily be done on > > the setup side of a plugin. Then, the special saving and > > loading is done through the application side of the same plugin.
> > I'm gonna get some rest and we'll see if what i just talked > > about makes sense tomorrow.. ;)
> > regards, > > joel
> > On 4/20/07, andy law (RI) <andy....@bbsrc.ac.uk> wrote:
> > Joel,
> > > 2). The explanation is clunky, and i'll try to simplify it, > > > but honestly, it boils down to clicking a few buttons and the > > > developers gets automatic encoding/decoding. i don't know of > > > any other library or even method of making it simpler... And > > > by default, encoding will be turned off because encoding will > > > truly only be needed in a production enviroment or at certain > > > points in the development.
> > > The gains performance-wise are simply too much to not push > > > the decode/ encode into the db. having personally used pog in > > > a large application really pushed the old pog to the limit...
> > > this can be further discussed though, and any other > > > suggestions for simplication will be appreciated...
> > More thinking out loud.
> > There are actually two issues here, now I think hard about it.
> > A) to encode or not to encode
> > B) to encode in php or in the database engine
> > *I* would like (A) to (ultimately) be configurable at > > the field level, > > rather than at the system level. i.e. I would like to > > be able to specify > > that field X of object Y is encoded but field A is not.
> > The ability to encode in the database is a property of > > the 'database' > > object, is it not, rather than the pog object? So > > should we be thinking > > about how to push that 'flag' into the database object too?
> > Streaming on from that, I can imagine a system that > > offers different > > types of encode/decode and chooses the correct place to do the > > transformation depending on capability.
> > Later,
> > Andy
> > ------------- > > Yada, yada, yada...
> > Roslin Institute is a company limited by guarantee, > > registered in > > Scotland (registered number SC157100) and a Scottish > > Charity (registered > > number SC023592). Our registered office is at Roslin, > > Midlothian, EH25 > > 9PS. VAT registration number 847380013.
> > The information contained in this e-mail (including any > > attachments) is > > confidential and is intended for the use of the > > addressee only. The > > opinions expressed within this e-mail (including any > > attachments) are > > the opinions of the sender and do not necessarily > > constitute those of > > Roslin Institute (Edinburgh) ("the Institute") unless > > specifically > > stated by a sender who is duly authorised to do so on > > behalf of the > > Institute.- Hide quoted text -
Oh.. and one thing that Mark just reminded me of... mysql 4 does not support custom stored procedures... so, this is another reason why, I believe, the base64 encoding feature should remain as a plugin...available on mysql 5 only. users working on mysql 4 simply need to disable encoding and everything will still be fine... (note if you have old data, you might have to convert them before upgrading to 3.0).
We could have gone other routes as well, such as asking the user what mysql version they are using and generating the code accordingly... but since db_encoding will be turned off by default, i don't think this is a viable solution. As Mark put it, not being able to use the base64 plugin on mysql 4 will, unfortunately, be the 'cost' of upgrading to 3.0...
However, we'll soon create tags within our SVN repository for the following versions:
2.4 => support databases other than mysql 2.6 => supports mysql 4+ only and the most reliable code so far 3.0 => supports mysql 4 (no data encoding) and mysql 5+, huge performance improvements (up to 40 times), and plugins
we will be actively developing the 3.0 branch and the other branches will be mostly for users wanting to easily access previous milestone versions.
regards, joel
On Apr 23, 10:11 am, Joel <joel...@gmail.com> wrote:
> i agree with your suggestions re: extending pog_attribute_type, making > it more customizable and also creating some base function that allows > easier manipulation. we'll make some changes for alpha 3 regarding > this and you can then provide some more feedback. I do appreciate > these suggestions as they're extremely useful IMHO.
> i do not fully agree with having to remove base64 as a plugin. It > should be looked at as a 'default' plugin which is why it is included > automatically in the package. it does have some hooks that no other > plugin will have (for e.g if the user has db_encoding = true and the > base64 function is not installed, setup will stop and give the user a > warning). the reason behind making base64 as a plugin v.s full hidden > integration within setup is, we wanted to eat our own dogfood and show > how plugins can be used. Moreover, we have an extensible platform, why > not use it ourselves...
> I do agree, however, that there could be some workflow improvements, > such as maybe discerning between plugins we provide and plugins that > are provided by third parties... So, i do agree that it can be > confusing the first time.
> This may be a bad example, but if you look at something like Firefox, > it consumes some plugins out-of-the-box such as their "talkback addon" > and another one i can't remember. The user is free to remove it, in > which case ffox won't send crash results to the ffox servers. > Likewise, if the user decides to get rid of the base64 plugin, there's > no issue. the only consequence is that pog will not be able to encode/ > decode data... but it'll still work ok.
> regards, > joel
> On Apr 23, 4:05 am, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> > Joel,
> > Some more rambling thoughts that occurred to me over the weekend, > > fuelled by a combination of tiredness, coffee and (bizzarrely) Champ Car > > racing on the telly.
> > The ability to base 64 encode/decode in the database is fundamental and > > should be part of the POG setup. I think it is distracting and confusing > > to have this as a plug-in. In addition, I think (as I said last week) > > that the 'db_encoding' preference and the 'db can encode' ability are > > two separate things.
> > I keep coming back to the per-field issue whenever I write code. The > > pog_attribute_type array is limiting in this respect as it has a > > complex, variable-length array embedded in it, with no simple way to > > inject other attributes alongside it. My gut instinct is screaming at me > > that this array should be altered and exposed as the *central* core of > > extensibility.
> > So I can define all manner of keyed parameters (required => true/false, > > acceptablePattern => <<regexp>>) etc and have a standard way of > > storing/retrieving them.
> > For ease of setting up extended attributes in subclasses, there could be > > a well-defined $pog_extra_attributes array that the standard constructor > > picked up and merged with the pog_attribute_type array.
> > Running on further form that, I wonder if there is then mileage in > > storing pre-canned snippets of SQL on a field-by-field basis within the > > atribute array which might then further speed up GetList() operations > > (since hash-based lookups are generally faster than if/then logic > > operations).
> > And now, back to what passes for *real* work :o{
> > Later,
> > Andy
> > ------------- > > Yada, yada, yada...
> > Roslin Institute is a company limited by guarantee, registered in > > Scotland (registered number SC157100) and a Scottish Charity (registered > > number SC023592). Our registered office is at Roslin, Midlothian, EH25 > > 9PS. VAT registration number 847380013.
> > The information contained in this e-mail (including any attachments) is > > confidential and is intended for the use of the addressee only. The > > opinions expressed within this e-mail (including any attachments) are > > the opinions of the sender and do not necessarily constitute those of > > Roslin Institute (Edinburgh) ("the Institute") unless specifically > > stated by a sender who is duly authorised to do so on behalf of the > > Institute.
> > > -----Original Message----- > > > From: Php-Object-Generator@googlegroups.com > > > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel Wan > > > Sent: 20 April 2007 12:26 > > > To: Php-Object-Generator@googlegroups.com > > > Subject: [Php-Object-Generator:1050] Re: POG 3.0 alpha available
> > > Hey Andy ;),
> > > agreed; whatever has been implemented so far was merely an > > > attempt to do what pog 2x was doing, but faster, and lay the > > > foundation for an architecture that's more extensible.
> > > The feature request to encode a specific field, as you > > > mentioned, has not been solved (and the base64 plugin is not > > > meant for this) .. and i now see where you're coming from...
> > > the base64 plugin is for the use case where you'd want to > > > encode everything since it eases programming. (user does not > > > have to be careful about characters etc).
> > > However, the request to encode specific field(s) is a > > > separate issue, IMHO and it does raise the questions you > > > mentioned above, and this is what i think:
> > > - encoding arbitrary fields using arbitrary encoding/decoding > > > algorithm is not a trivial problem to solve, especially if we > > > still want performance, searching of the encoded data, and > > > ease of use. Attempting to add this functionality to the POG > > > Core would have a huge cost in terms of complexity and ease of use.
> > > But i can still totally see that feature being implemented as > > > a plugin. To specify the fields to be encoded (and pushing > > > these flags to the db as you mentioned) can easily be done on > > > the setup side of a plugin. Then, the special saving and > > > loading is done through the application side of the same plugin.
> > > I'm gonna get some rest and we'll see if what i just talked > > > about makes sense tomorrow.. ;)
> > > regards, > > > joel
> > > On 4/20/07, andy law (RI) <andy....@bbsrc.ac.uk> wrote:
> > > Joel,
> > > > 2). The explanation is clunky, and i'll try to simplify it, > > > > but honestly, it boils down to clicking a few buttons and the > > > > developers gets automatic encoding/decoding. i don't know of > > > > any other library or even method of making it simpler... And > > > > by default, encoding will be turned off because encoding will > > > > truly only be needed in a production enviroment or at certain > > > > points in the development.
> > > > The gains performance-wise are simply too much to not push > > > > the decode/ encode into the db. having personally used pog in > > > > a large application really pushed the old pog to the limit...
> > > > this can be further discussed though, and any other > > > > suggestions for simplication will be appreciated...
> > > More thinking out loud.
> > > There are actually two issues here, now I think hard about it.
> > > A) to encode or not to encode
> > > B) to encode in php or in the database engine
> > > *I* would like (A) to (ultimately) be configurable at > > > the field level, > > > rather than at the system level. i.e. I would like to > > > be able to specify
> i agree with your suggestions re: extending > pog_attribute_type, making it more customizable and also > creating some base function that allows easier manipulation. > we'll make some changes for alpha 3 regarding this and you > can then provide some more feedback. I do appreciate these > suggestions as they're extremely useful IMHO.
Please let me know if I start to p**s you off with all this grumping :o}. It's meant in a constructive way and I really appreciate the tool that you guys have built here.
> i do not fully agree with having to remove base64 as a > plugin. It should be looked at as a 'default' plugin which is > why it is included automatically in the package. it does have > some hooks that no other plugin will have (for e.g if the > user has db_encoding = true and the > base64 function is not installed, setup will stop and give > the user a warning). the reason behind making base64 as a > plugin v.s full hidden integration within setup is, we wanted > to eat our own dogfood and show how plugins can be used. > Moreover, we have an extensible platform, why not use it ourselves...
I think that *my* problem (note, *my* problem, not yours) is that I haven't fully transformed my view of what the plug-in should be doing (extending the *objects* - kind of like a poor man's multiple inheritance but injected at run-time rather than code-time) into what I think your view of what they are there for (to extend the *system*). I suspect that they are the same thing, but I haven't done the mental re-engineering to allow myself to think it through properly.
Your base_64 plugin though should have no bearing whatsoever on the functionality of *any* code that consumes POG objects, whereas many of the other things that we have spoken about in the past (form generators, object validators) do. By that, I mean that if we write an object validator, the controller code that wants to know if an object is valid has to know about the validation routines which it will get at through calling an object function ($object->isValid()). However, I can't think of any reason why calling code would ever care about anything that the base_64 plugin does because the encoding/decoding is at the persistence level and should have been dealt with by the time any external code gets to interact with an object.
Also, I genuinely *do* have a problem (now that I have thought hard and separated out the two concerns - see email from yesterday, quoted way below here) about what you are doing with the db_encoding flag in the configuration file which is to fundamentally change its meaning. Currently (2.x versions), this flag means 'I [would/would not] like all text fields to be base_64 encoded before storing in the database'. Under 3.x alpha, this flag now seems to mean a combination of the above plus 'the database can encode using a stored procedure'. Two separate flags seems a necessity.
In fact, the second flag (the database can encode) is less of a configuration and more of a property which the database connection object can determine for itself at runtime, so probably shouldn't be in the configuration file at all.
I'm rambling again now - I'm going to go back and look to see if I can work out an efficient way to allow the user to specify encoding or not encoding and be able to use the stored procedure if it is available or basic php-based encoding if it is not (backwards compatibility).
Later,
Andy
------------- Yada, yada, yada...
Roslin Institute is a company limited by guarantee, registered in Scotland (registered number SC157100) and a Scottish Charity (registered number SC023592). Our registered office is at Roslin, Midlothian, EH25 9PS. VAT registration number 847380013.
The information contained in this e-mail (including any attachments) is confidential and is intended for the use of the addressee only. The opinions expressed within this e-mail (including any attachments) are the opinions of the sender and do not necessarily constitute those of Roslin Institute (Edinburgh) ("the Institute") unless specifically stated by a sender who is duly authorised to do so on behalf of the Institute.
> I do agree, however, that there could be some workflow > improvements, such as maybe discerning between plugins we > provide and plugins that are provided by third parties... So, > i do agree that it can be confusing the first time.
> This may be a bad example, but if you look at something like > Firefox, it consumes some plugins out-of-the-box such as > their "talkback addon" > and another one i can't remember. The user is free to remove > it, in which case ffox won't send crash results to the ffox servers. > Likewise, if the user decides to get rid of the base64 > plugin, there's no issue. the only consequence is that pog > will not be able to encode/ decode data... but it'll still work ok.
> regards, > joel
> On Apr 23, 4:05 am, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote: > > Joel,
> > Some more rambling thoughts that occurred to me over the weekend, > > fuelled by a combination of tiredness, coffee and > (bizzarrely) Champ > > Car racing on the telly.
> > The ability to base 64 encode/decode in the database is fundamental > > and should be part of the POG setup. I think it is distracting and > > confusing to have this as a plug-in. In addition, I think > (as I said > > last week) that the 'db_encoding' preference and the 'db > can encode' > > ability are two separate things.
> > I keep coming back to the per-field issue whenever I write > code. The > > pog_attribute_type array is limiting in this respect as it has a > > complex, variable-length array embedded in it, with no > simple way to > > inject other attributes alongside it. My gut instinct is > screaming at > > me that this array should be altered and exposed as the > *central* core > > of extensibility.
> > So I can define all manner of keyed parameters (required => > > true/false, acceptablePattern => <<regexp>>) etc and have a > standard > > way of storing/retrieving them.
> > For ease of setting up extended attributes in subclasses, > there could > > be a well-defined $pog_extra_attributes array that the standard > > constructor picked up and merged with the pog_attribute_type array.
> > Running on further form that, I wonder if there is then mileage in > > storing pre-canned snippets of SQL on a field-by-field basis within > > the atribute array which might then further speed up GetList() > > operations (since hash-based lookups are generally faster > than if/then > > logic operations).
> > And now, back to what passes for *real* work :o{
> > Later,
> > Andy
> > ------------- > > Yada, yada, yada...
> > Roslin Institute is a company limited by guarantee, registered in > > Scotland (registered number SC157100) and a Scottish Charity > > (registered number SC023592). Our registered office is at Roslin, > > Midlothian, EH25 9PS. VAT registration number 847380013.
> > The information contained in this e-mail (including any > attachments) is > > confidential and is intended for the use of the addressee > only. The > > opinions expressed within this e-mail (including any > attachments) are > > the opinions of the sender and do not necessarily > constitute those of > > Roslin Institute (Edinburgh) ("the Institute") unless specifically > > stated by a sender who is duly authorised to do so on behalf of the > > Institute.
> > > -----Original Message----- > > > From: Php-Object-Generator@googlegroups.com > > > [mailto:Php-Object-Generator@googlegroups.com] On Behalf > Of Joel Wan > > > Sent: 20 April 2007 12:26 > > > To: Php-Object-Generator@googlegroups.com > > > Subject: [Php-Object-Generator:1050] Re: POG 3.0 alpha available
> > > Hey Andy ;),
> > > agreed; whatever has been implemented so far was merely > an attempt > > > to do what pog 2x was doing, but faster, and lay the > foundation for > > > an architecture that's more extensible.
> > > The feature request to encode a specific field, as you mentioned, > > > has not been solved (and the base64 plugin is not meant > for this) .. > > > and i now see where you're coming from...
> > > the base64 plugin is for the use case where you'd want to encode > > > everything since it eases programming. (user does not have to be > > > careful about characters etc).
> > > However, the request to encode specific field(s) is a separate > > > issue, IMHO and it does raise the questions you mentioned > above, and > > > this is
Might I ask how you load your objects in your pog scripts/applications?
1. Coding includes for each object needed at the start of your script? 2. having a function to load all objects at the start of your application? 3. using the __autoload function (only php 5) do load object files as needed? (http://www.php.net/autoload)
Just asking this since it might help POG developers if method 2 or 3 was built in. Or any other smart way I am not aware of.
Regards,
Paris Paraskeva Managing Director M.E. & E. United Worx Ltd 33, Apostolou Pavlou Avenue, Office 103, 8046 Paphos, Cyprus Tel.: +357 26220707, +357 26221313, Mob.: +357 99575501 Fax.: +357 26221002 pa...@unitedworx.com www.unitedworx.com
The information contained in this email message(and any attachments) is legally privileged and confidential information intended only for the use of the addressee(s) listed on this email. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution or copy of this email is strictly prohibited. If you have received this email in error, please notify us by telephone or email on the contact details shown on the end of this email. Thank you.
[mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel Sent: Tuesday, April 24, 2007 5:44 AM To: Php Object Generator Subject: [Php-Object-Generator:1056] Re: POG 3.0 alpha available
Oh.. and one thing that Mark just reminded me of... mysql 4 does not support custom stored procedures... so, this is another reason why, I believe, the base64 encoding feature should remain as a plugin...available on mysql 5 only. users working on mysql 4 simply need to disable encoding and everything will still be fine... (note if you have old data, you might have to convert them before upgrading to 3.0).
We could have gone other routes as well, such as asking the user what mysql version they are using and generating the code accordingly... but since db_encoding will be turned off by default, i don't think this is a viable solution. As Mark put it, not being able to use the base64 plugin on mysql 4 will, unfortunately, be the 'cost' of upgrading to 3.0...
However, we'll soon create tags within our SVN repository for the following versions:
2.4 => support databases other than mysql 2.6 => supports mysql 4+ only and the most reliable code so far 3.0 => supports mysql 4 (no data encoding) and mysql 5+, huge performance improvements (up to 40 times), and plugins
we will be actively developing the 3.0 branch and the other branches will be mostly for users wanting to easily access previous milestone versions.
regards, joel
On Apr 23, 10:11 am, Joel <joel...@gmail.com> wrote: > Hi Andy,
> i agree with your suggestions re: extending pog_attribute_type, making > it more customizable and also creating some base function that allows > easier manipulation. we'll make some changes for alpha 3 regarding > this and you can then provide some more feedback. I do appreciate > these suggestions as they're extremely useful IMHO.
> i do not fully agree with having to remove base64 as a plugin. It > should be looked at as a 'default' plugin which is why it is included > automatically in the package. it does have some hooks that no other > plugin will have (for e.g if the user has db_encoding = true and the > base64 function is not installed, setup will stop and give the user a > warning). the reason behind making base64 as a plugin v.s full hidden > integration within setup is, we wanted to eat our own dogfood and show > how plugins can be used. Moreover, we have an extensible platform, why > not use it ourselves...
> I do agree, however, that there could be some workflow improvements, > such as maybe discerning between plugins we provide and plugins that > are provided by third parties... So, i do agree that it can be > confusing the first time.
> This may be a bad example, but if you look at something like Firefox, > it consumes some plugins out-of-the-box such as their "talkback addon" > and another one i can't remember. The user is free to remove it, in > which case ffox won't send crash results to the ffox servers. > Likewise, if the user decides to get rid of the base64 plugin, there's > no issue. the only consequence is that pog will not be able to encode/ > decode data... but it'll still work ok.
> regards, > joel
> On Apr 23, 4:05 am, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> > Joel,
> > Some more rambling thoughts that occurred to me over the weekend, > > fuelled by a combination of tiredness, coffee and (bizzarrely) Champ Car > > racing on the telly.
> > The ability to base 64 encode/decode in the database is fundamental and > > should be part of the POG setup. I think it is distracting and confusing > > to have this as a plug-in. In addition, I think (as I said last week) > > that the 'db_encoding' preference and the 'db can encode' ability are > > two separate things.
> > I keep coming back to the per-field issue whenever I write code. The > > pog_attribute_type array is limiting in this respect as it has a > > complex, variable-length array embedded in it, with no simple way to > > inject other attributes alongside it. My gut instinct is screaming at me > > that this array should be altered and exposed as the *central* core of > > extensibility.
> > So I can define all manner of keyed parameters (required => true/false, > > acceptablePattern => <<regexp>>) etc and have a standard way of > > storing/retrieving them.
> > For ease of setting up extended attributes in subclasses, there could be > > a well-defined $pog_extra_attributes array that the standard constructor > > picked up and merged with the pog_attribute_type array.
> > Running on further form that, I wonder if there is then mileage in > > storing pre-canned snippets of SQL on a field-by-field basis within the > > atribute array which might then further speed up GetList() operations > > (since hash-based lookups are generally faster than if/then logic > > operations).
> > And now, back to what passes for *real* work :o{
> > Later,
> > Andy
> > ------------- > > Yada, yada, yada...
> > Roslin Institute is a company limited by guarantee, registered in > > Scotland (registered number SC157100) and a Scottish Charity (registered > > number SC023592). Our registered office is at Roslin, Midlothian, EH25 > > 9PS. VAT registration number 847380013.
> > The information contained in this e-mail (including any attachments) is > > confidential and is intended for the use of the addressee only. The > > opinions expressed within this e-mail (including any attachments) are > > the opinions of the sender and do not necessarily constitute those of > > Roslin Institute (Edinburgh) ("the Institute") unless specifically > > stated by a sender who is duly authorised to do so on behalf of the > > Institute.
> > > -----Original Message----- > > > From: Php-Object-Generator@googlegroups.com > > > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel Wan > > > Sent: 20 April 2007 12:26 > > > To: Php-Object-Generator@googlegroups.com > > > Subject: [Php-Object-Generator:1050] Re: POG 3.0 alpha available
> > > Hey Andy ;),
> > > agreed; whatever has been implemented so far was merely an > > > attempt to do what pog 2x was doing, but faster, and lay the > > > foundation for an architecture that's more extensible.
> > > The feature request to encode a specific field, as you > > > mentioned, has not been solved (and the base64 plugin is not > > > meant for this) .. and i now see where you're coming from...
> > > the base64 plugin is for the use case where you'd want to > > > encode everything since it eases programming. (user does not > > > have to be careful about characters etc).
> > > However, the request to encode specific field(s) is a > > > separate issue, IMHO and it does raise the questions you > > > mentioned above, and this is what i think:
> > > - encoding arbitrary fields using arbitrary encoding/decoding > > > algorithm is not a trivial problem to solve, especially if we > > > still want performance, searching of the encoded data, and > > > ease of use. Attempting to add this functionality to the POG > > > Core would have a huge cost in terms of complexity and ease of use.
> > > But i can still totally see that feature being implemented as > > > a plugin. To specify the fields to be encoded (and pushing > > > these flags to the db as you mentioned) can easily be done on > > > the setup side of
Main template for each site includes a global include file.
Global include file includes each class in turn so I only have to maintain one file.
You're right though - since we have in POG 3 a function that lists AllObjects(), presumably that could be modified to include those files so we'd only have to include one file.
However, since that only includes POG-specific files, I'd still have to have a global include file to incorporate all the other files and functions that I need.
Later,
Andy
------------- Yada, yada, yada...
Roslin Institute is a company limited by guarantee, registered in Scotland (registered number SC157100) and a Scottish Charity (registered number SC023592). Our registered office is at Roslin, Midlothian, EH25 9PS. VAT registration number 847380013.
The information contained in this e-mail (including any attachments) is confidential and is intended for the use of the addressee only. The opinions expressed within this e-mail (including any attachments) are the opinions of the sender and do not necessarily constitute those of Roslin Institute (Edinburgh) ("the Institute") unless specifically stated by a sender who is duly authorised to do so on behalf of the Institute.
> -----Original Message----- > From: Php-Object-Generator@googlegroups.com > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of > Paris Paraskeva > Sent: 24 April 2007 14:12 > To: Php-Object-Generator@googlegroups.com > Subject: [Php-Object-Generator:1060] autoload objects
> Hi all,
> It's nice to see things moving along with POG3.
> Might I ask how you load your objects in your pog > scripts/applications?
> 1. Coding includes for each object needed at the start of your script? > 2. having a function to load all objects at the start of your > application? > 3. using the __autoload function (only php 5) do load object > files as needed? (http://www.php.net/autoload)
> Just asking this since it might help POG developers if method > 2 or 3 was built in. Or any other smart way I am not aware of.
> Regards,
> Paris Paraskeva > Managing Director > M.E. & E. United Worx Ltd > 33, Apostolou Pavlou Avenue, Office 103, 8046 Paphos, Cyprus > Tel.: +357 26220707, +357 26221313, Mob.: +357 99575501 > Fax.: +357 26221002 > pa...@unitedworx.com > www.unitedworx.com
> The information contained in this email message(and any > attachments) is legally privileged and confidential > information intended only for the use of the addressee(s) > listed on this email. If the reader of this message is not > the intended recipient you are hereby notified that any > dissemination, distribution or copy of this email is strictly > prohibited. If you have received this email in error, please > notify us by telephone or email on the contact details shown > on the end of this email. Thank you.
> -----Original Message----- > From: Php-Object-Generator@googlegroups.com > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel > Sent: Tuesday, April 24, 2007 5:44 AM > To: Php Object Generator > Subject: [Php-Object-Generator:1056] Re: POG 3.0 alpha available
> Oh.. and one thing that Mark just reminded me of... mysql 4 > does not support custom stored procedures... so, this is > another reason why, I believe, the base64 encoding feature > should remain as a plugin...available on mysql 5 only. users > working on mysql 4 simply need to disable encoding and > everything will still be fine... (note if you have old data, > you might have to convert them before upgrading to 3.0).
> We could have gone other routes as well, such as asking the > user what mysql version they are using and generating the > code accordingly... > but since db_encoding will be turned off by default, i don't > think this is a viable solution. As Mark put it, not being > able to use the > base64 plugin on mysql 4 will, unfortunately, be the 'cost' > of upgrading to 3.0...
> However, we'll soon create tags within our SVN repository for > the following versions:
> 2.4 => support databases other than mysql > 2.6 => supports mysql 4+ only and the most reliable code so > far 3.0 => supports mysql 4 (no data encoding) and mysql 5+, > huge performance improvements (up to 40 times), and plugins
> we will be actively developing the 3.0 branch and the other > branches will be mostly for users wanting to easily access > previous milestone versions.
> regards, > joel
> On Apr 23, 10:11 am, Joel <joel...@gmail.com> wrote: > > Hi Andy,
> > i agree with your suggestions re: extending > pog_attribute_type, making > > it more customizable and also creating some base function > that allows > > easier manipulation. we'll make some changes for alpha 3 regarding > > this and you can then provide some more feedback. I do appreciate > > these suggestions as they're extremely useful IMHO.
> > i do not fully agree with having to remove base64 as a plugin. It > > should be looked at as a 'default' plugin which is why it > is included > > automatically in the package. it does have some hooks that no other > > plugin will have (for e.g if the user has db_encoding = true and the > > base64 function is not installed, setup will stop and give > the user a > > warning). the reason behind making base64 as a plugin v.s > full hidden > > integration within setup is, we wanted to eat our own > dogfood and show > > how plugins can be used. Moreover, we have an extensible > platform, why > > not use it ourselves...
> > I do agree, however, that there could be some workflow > improvements, > > such as maybe discerning between plugins we provide and > plugins that > > are provided by third parties... So, i do agree that it can be > > confusing the first time.
> > This may be a bad example, but if you look at something > like Firefox, > > it consumes some plugins out-of-the-box such as their > "talkback addon" > > and another one i can't remember. The user is free to remove it, in > > which case ffox won't send crash results to the ffox servers. > > Likewise, if the user decides to get rid of the base64 > plugin, there's > > no issue. the only consequence is that pog will not be able > to encode/ > > decode data... but it'll still work ok.
> > regards, > > joel
> > On Apr 23, 4:05 am, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> > > Joel,
> > > Some more rambling thoughts that occurred to me over the weekend, > > > fuelled by a combination of tiredness, coffee and > (bizzarrely) Champ > > > Car racing on the telly.
> > > The ability to base 64 encode/decode in the database is > fundamental > > > and should be part of the POG setup. I think it is > distracting and > > > confusing to have this as a plug-in. In addition, I think > (as I said > > > last week) that the 'db_encoding' preference and the 'db > can encode' > > > ability are two separate things.
> > > I keep coming back to the per-field issue whenever I > write code. The > > > pog_attribute_type array is limiting in this respect as it has a > > > complex, variable-length array embedded in it, with no > simple way to > > > inject other attributes alongside it. My gut instinct is > screaming > > > at me that this array should be altered and exposed as > the *central* > > > core of extensibility.
> > > So I can define all manner of keyed parameters (required => > > > true/false, acceptablePattern => <<regexp>>) etc and have > a standard > > > way of storing/retrieving them.
> > > For ease of setting up extended attributes in subclasses, there > > > could be a well-defined $pog_extra_attributes array that the > > > standard constructor picked up and merged with the > pog_attribute_type array.
> > > Running on further form that, I wonder if there is then > mileage in > > > storing pre-canned snippets of SQL on a field-by-field > basis within > > > the atribute array which might then further speed up GetList() > > > operations (since hash-based lookups are generally faster than > > > if/then logic operations).
> > > And now, back to what passes for *real* work :o{
> > > Later,
> > > Andy
> > > ------------- > > > Yada, yada, yada...
> > > Roslin Institute is a company limited by guarantee, registered in > > > Scotland (registered number SC157100) and a Scottish Charity > > > (registered number SC023592). Our registered office is at Roslin, > > > Midlothian, EH25 9PS. VAT registration number
I think I can speak to the base-64 encode/decode a little - and hopefully relieve some anxiety.
-Mark
> Your base_64 plugin though should have no bearing whatsoever on the > functionality of *any* code that consumes POG objects,
agreed - remains the same - all application code must remain ignorant of storage.
> whereas many of > the other things that we have spoken about in the past (form generators, > object validators) do. By that, I mean that if we write an object > validator, the controller code that wants to know if an object is valid > has to know about the validation routines which it will get at through > calling an object function ($object->isValid()). However, I can't think > of any reason why calling code would ever care about anything that the > base_64 plugin does because the encoding/decoding is at the persistence > level and should have been dealt with by the time any external code gets > to interact with an object.
almost always true - but we've come across a few esoteric examples where a plugin needs to know how things are stored... writing database manipulation plugins, for example, for advanced uses. New plugins will show how often the need is actually present - I expect it to be rare -- but my crystal ball is broken.
> Also, I genuinely *do* have a problem (now that I have thought hard and > separated out the two concerns - see email from yesterday, quoted way > below here) about what you are doing with the db_encoding flag in the > configuration file which is to fundamentally change its meaning. > Currently (2.x versions), this flag means 'I [would/would not] like all > text fields to be base_64 encoded before storing in the database'. Under > 3.x alpha, this flag now seems to mean a combination of the above plus > 'the database can encode using a stored procedure'. Two separate flags > seems a necessity.
I have a feeling you may have got onto a tangent here and confused the intention.
The POG v3 objects have the advantage (using mysql 5 stored procedure) to do more complex and quicker queries (sorting, odering, etc) internally using the stored procedure decoding (both an advantage and disadvantage). The flag simply indicates whether or not the data is indeed stored encoded - thus using (requiring) the appropriate routines at run time (within the database). This means that the POG objects only care about the encoding/decoding during the db interactions (as they were before) - and 1 flag is still correct (duality is not a concern). I suggest looking at a GetList function with POG 3 - and I think it will become more clear what I'm trying to get at.
So, the semantic meaning remains the same, however the implications now reach into the database (for perfomance reasons), whereas before (version 1&2), it did not require the database to support more functionality.
> In fact, the second flag (the database can encode) is less of a > configuration and more of a property which the database connection > object can determine for itself at runtime, so probably shouldn't be in > the configuration file at all.
I myself use an application top, include file, which finds and loads all objects so I don't have to bother including new objects in my application. Just pointing this out since it could make things easier for others. Since pog has a configuration file which handles connection to the db it could call and include all objects as well so we would forget all about loading the objects and deal with other application specific stuff.
(using Zend Sudio here for php and dreamweaver for html/css)
Regards,
Paris Paraskeva Managing Director M.E. & E. United Worx Ltd 33, Apostolou Pavlou Avenue, Office 103, 8046 Paphos, Cyprus Tel.: +357 26220707, +357 26221313, Mob.: +357 99575501 Fax.: +357 26221002 pa...@unitedworx.com www.unitedworx.com
The information contained in this email message(and any attachments) is legally privileged and confidential information intended only for the use of the addressee(s) listed on this email. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution or copy of this email is strictly prohibited. If you have received this email in error, please notify us by telephone or email on the contact details shown on the end of this email. Thank you.
[mailto:Php-Object-Generator@googlegroups.com] On Behalf Of andy law (RI) Sent: Tuesday, April 24, 2007 11:49 PM To: Php-Object-Generator@googlegroups.com Subject: [Php-Object-Generator:1062] Re: autoload objects
Paris,
Websites in DreamWeaver
Main template for each site includes a global include file.
Global include file includes each class in turn so I only have to maintain one file.
You're right though - since we have in POG 3 a function that lists AllObjects(), presumably that could be modified to include those files so we'd only have to include one file.
However, since that only includes POG-specific files, I'd still have to have a global include file to incorporate all the other files and functions that I need.
Later,
Andy
------------- Yada, yada, yada...
Roslin Institute is a company limited by guarantee, registered in Scotland (registered number SC157100) and a Scottish Charity (registered number SC023592). Our registered office is at Roslin, Midlothian, EH25 9PS. VAT registration number 847380013.
The information contained in this e-mail (including any attachments) is confidential and is intended for the use of the addressee only. The opinions expressed within this e-mail (including any attachments) are the opinions of the sender and do not necessarily constitute those of Roslin Institute (Edinburgh) ("the Institute") unless specifically stated by a sender who is duly authorised to do so on behalf of the Institute.
> -----Original Message----- > From: Php-Object-Generator@googlegroups.com > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of > Paris Paraskeva > Sent: 24 April 2007 14:12 > To: Php-Object-Generator@googlegroups.com > Subject: [Php-Object-Generator:1060] autoload objects
> Hi all,
> It's nice to see things moving along with POG3.
> Might I ask how you load your objects in your pog > scripts/applications?
> 1. Coding includes for each object needed at the start of your script? > 2. having a function to load all objects at the start of your > application? > 3. using the __autoload function (only php 5) do load object > files as needed? (http://www.php.net/autoload)
> Just asking this since it might help POG developers if method > 2 or 3 was built in. Or any other smart way I am not aware of.
> Regards,
> Paris Paraskeva > Managing Director > M.E. & E. United Worx Ltd > 33, Apostolou Pavlou Avenue, Office 103, 8046 Paphos, Cyprus > Tel.: +357 26220707, +357 26221313, Mob.: +357 99575501 > Fax.: +357 26221002 > pa...@unitedworx.com > www.unitedworx.com
> The information contained in this email message(and any > attachments) is legally privileged and confidential > information intended only for the use of the addressee(s) > listed on this email. If the reader of this message is not > the intended recipient you are hereby notified that any > dissemination, distribution or copy of this email is strictly > prohibited. If you have received this email in error, please > notify us by telephone or email on the contact details shown > on the end of this email. Thank you.
> -----Original Message----- > From: Php-Object-Generator@googlegroups.com > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel > Sent: Tuesday, April 24, 2007 5:44 AM > To: Php Object Generator > Subject: [Php-Object-Generator:1056] Re: POG 3.0 alpha available
> Oh.. and one thing that Mark just reminded me of... mysql 4 > does not support custom stored procedures... so, this is > another reason why, I believe, the base64 encoding feature > should remain as a plugin...available on mysql 5 only. users > working on mysql 4 simply need to disable encoding and > everything will still be fine... (note if you have old data, > you might have to convert them before upgrading to 3.0).
> We could have gone other routes as well, such as asking the > user what mysql version they are using and generating the > code accordingly... > but since db_encoding will be turned off by default, i don't > think this is a viable solution. As Mark put it, not being > able to use the > base64 plugin on mysql 4 will, unfortunately, be the 'cost' > of upgrading to 3.0...
> However, we'll soon create tags within our SVN repository for > the following versions:
> 2.4 => support databases other than mysql > 2.6 => supports mysql 4+ only and the most reliable code so > far 3.0 => supports mysql 4 (no data encoding) and mysql 5+, > huge performance improvements (up to 40 times), and plugins
> we will be actively developing the 3.0 branch and the other > branches will be mostly for users wanting to easily access > previous milestone versions.
> regards, > joel
> On Apr 23, 10:11 am, Joel <joel...@gmail.com> wrote: > > Hi Andy,
> > i agree with your suggestions re: extending > pog_attribute_type, making > > it more customizable and also creating some base function > that allows > > easier manipulation. we'll make some changes for alpha 3 regarding > > this and you can then provide some more feedback. I do appreciate > > these suggestions as they're extremely useful IMHO.
> > i do not fully agree with having to remove base64 as a plugin. It > > should be looked at as a 'default' plugin which is why it > is included > > automatically in the package. it does have some hooks that no other > > plugin will have (for e.g if the user has db_encoding = true and the > > base64 function is not installed, setup will stop and give > the user a > > warning). the reason behind making base64 as a plugin v.s > full hidden > > integration within setup is, we wanted to eat our own > dogfood and show > > how plugins can be used. Moreover, we have an extensible > platform, why > > not use it ourselves...
> > I do agree, however, that there could be some workflow > improvements, > > such as maybe discerning between plugins we provide and > plugins that > > are provided by third parties... So, i do agree that it can be > > confusing the first time.
> > This may be a bad example, but if you look at something > like Firefox, > > it consumes some plugins out-of-the-box such as their > "talkback addon" > > and another one i can't remember. The user is free to remove it, in > > which case ffox won't send crash results to the ffox servers. > > Likewise, if the user decides to get rid of the base64 > plugin, there's > > no issue. the only consequence is that pog will not be able > to encode/ > > decode data... but it'll still work ok.
> > regards, > > joel
> > On Apr 23, 4:05 am, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> > > Joel,
> > > Some more rambling thoughts that occurred to me over the weekend, > > > fuelled by a combination of tiredness, coffee and > (bizzarrely) Champ > > > Car racing on the telly.
> > > The ability to base 64 encode/decode in the database is > fundamental > > > and should be part of the POG setup. I think it is > distracting and > > > confusing to have this as a plug-in. In addition, I think > (as I said > > > last week) that the 'db_encoding' preference and the 'db > can encode' > > > ability are two separate things.
> > > I keep coming back to the per-field issue whenever I > write code. The > > > pog_attribute_type array is limiting in this respect as it has a > > > complex, variable-length array embedded in it, with no > simple way to > > > inject other attributes alongside it. My gut instinct is > screaming > > > at me that this array should be altered and exposed as > the *central* > > > core of extensibility.
> I myself use an application top, include file, which finds and loads all > objects so I don't have to bother including new objects in my application. > Just pointing this out since it could make things easier for others. Since > pog has a configuration file which handles connection to the db it could > call and include all objects as well so we would forget all about loading > the objects and deal with other application specific stuff.
Hallo, if I may share my solution: first, I create autoload function file with a function (you can see at http://www.rozkovec.info/autoloadFunctionSetup.php.txt ), which recursively scans given directories and for each PHP file creates a line in __autoload function, so the generated function then looks something like this: Then I have one configuration file which I include everywhere. When adding some classes I only run the setup again (on my developer machine i am running with every script load, so I do not have to bother with it)
Changes from previous revision: [fix] standardized pog base _call interface [fix] made pog_attribute_type more extendable (user request) [updated] updated test apps [fix] one-click upgrade supports connection via proxy server (user request)
Let us know if you encounter any issue. Once again, your feedback is greatly appreciated.
> > I myself use an application top, include file, which finds and loads all > > objects so I don't have to bother including new objects in my application. > > Just pointing this out since it could make things easier for others. Since > > pog has a configuration file which handles connection to the db it could > > call and include all objects as well so we would forget all about loading > > the objects and deal with other application specific stuff.
> Hallo, > if I may share my solution: > first, I create autoload function file with a function (you can see athttp://www.rozkovec.info/autoloadFunctionSetup.php.txt), which > recursively scans given directories and for each PHP file creates a > line in __autoload function, so the generated function then looks > something like this: > Then I have one configuration file which I include everywhere. > When adding some classes I only run the setup again (on my developer > machine i am running with every script load, so I do not have to > bother with it)
- all create tables now have 'engine=myisam' in case the system is not configured for myisam by default. - plugins folder is now configurable via configuation.php
On May 16, 7:02 pm, Joel <joel...@gmail.com> wrote:
> Changes from previous revision: > [fix] standardized pog base _call interface > [fix] made pog_attribute_type more extendable (user request) > [updated] updated test apps > [fix] one-click upgrade supports connection via proxy server (user > request)
> Let us know if you encounter any issue. Once again, your feedback is > greatly appreciated.
> Regards, > Joel
> On Apr 28, 8:51 am, cvokk <c...@seznam.cz> wrote:
> > Paris Paraskeva napsal:
> > > I myself use an application top, include file, which finds and loads all > > > objects so I don't have to bother including new objects in my application. > > > Just pointing this out since it could make things easier for others. Since > > > pog has a configuration file which handles connection to the db it could > > > call and include all objects as well so we would forget all about loading > > > the objects and deal with other application specific stuff.
> > Hallo, > > if I may share my solution: > > first, I create autoload function file with a function (you can see athttp://www.rozkovec.info/autoloadFunctionSetup.php.txt), which > > recursively scans given directories and for each PHP file creates a > > line in __autoload function, so the generated function then looks > > something like this: > > Then I have one configuration file which I include everywhere. > > When adding some classes I only run the setup again (on my developer > > machine i am running with every script load, so I do not have to > > bother with it)
I was just wondering what are the differenced in code generated for PHP 4 and code generated for PHP 5. I had PHP 5 locally and PHP 4 online so i was generating PHP 4 objects, however now I am using PHP 5 both locally and on-line. I am keep generating objects for PHP 4 like I always did since it works fine. Should I regenerate my objects to PHP 5 is there an advantage to do so? What's different in generated objects code?
Sorry if this question sounds stupid but I want to make sure what different with PHP 4 and PHP 5 POG generated code.
- usage of private/public for methods and variables, making the functions and variables more secure - support for interfaces - if you're using lots of relations (parents/children/siblings etc) i would strongly suggest your use php5 generated code for the reasons reported here: http://groups.google.com/group/Php-Object-Generator/browse_thread/thr... - if you plan to use plugins (in 3.0), i again suggest you use php5 generated code.
else, almost everything in terms of performance, security, reliability is the same.
regards
On Jun 13, 12:29 am, "Paris Paraskeva" <p...@unitedworx.com> wrote:
> I was just wondering what are the differenced in code generated for PHP 4 > and code generated for PHP 5. I had PHP 5 locally and PHP 4 online so i was > generating PHP 4 objects, however now I am using PHP 5 both locally and > on-line. I am keep generating objects for PHP 4 like I always did since it > works fine. Should I regenerate my objects to PHP 5 is there an advantage to > do so? What's different in generated objects code?
> Sorry if this question sounds stupid but I want to make sure what different > with PHP 4 and PHP 5 POG generated code.
