POG 3.0 alpha available
Joel
repository.
The version has also been refreshed on http://beta.phpobjectgenerator.com
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.
Thread references:
http://groups.google.com/group/Php-Object-Generator/browse_thread/thread/8d1e6d6016bbdd5e
http://groups.google.com/group/Php-Object-Generator/browse_thread/thread/6210655c137fa200
andy law (RI)
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.
Paris Paraskeva
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.
-----Original Message-----
From: Php-Object...@googlegroups.com
[mailto:Php-Object...@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.
The version has also been refreshed on http://beta.phpobjectgenerator.com
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.
Thread references:
http://groups.google.com/group/Php-Object-Generator/browse_thread/thread/8d1
e6d6016bbdd5e
http://groups.google.com/group/Php-Object-Generator/browse_thread/thread/621
0655c137fa200
__________ NOD32 2202 (20070418) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
Joel
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.
#1 and #2 give a significant performance boost as outlined here:
http://www.phpobjectgenerator.com/plog/article/146/initial-performance-results
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/browse_thread/thread/a4fea3bec0b3725f/
- 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.
> - Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Joel
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.
>
> #1 and #2 give a significant performance boost as outlined here:http://www.phpobjectgenerator.com/plog/article/146/initial-performanc...
> $across. See this for more details:http://groups.google.com/group/Php-Object-Generator/browse_thread/thr...
andy law (RI)
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.
Joel
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
> ...
>
> read more »- Hide quoted text -
Joel
>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.?
Joel
be handled by us. The user won't have to do anything different than
php5+
> ...
>
> read more »
Joel
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,
> ...
>
> read more »
andy law (RI)
> 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.
Joel Wan
andy law (RI)
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.
Would changing
var $pog_attribute_type = array(
"userId" => array("NUMERIC", "INT"),
"firstname" => array("TEXT", "CHAR", "40"),
"lastname" => array("TEXT", "CHAR", "40")
);
To
var $pog_attribute_type = array(
"userId" => array( "_pog_dbattributes" =>
array("NUMERIC", "INT")),
"firstname" => array( "_pog_dbattributes" =>
array("TEXT", "CHAR", "40")),
"lastname" => array( "_pog_dbattributes" =>
array("TEXT", "CHAR", "40"))
)
Be a problem?
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.
Joel
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
> > Institute.- Hide quoted text -
Joel
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
andy law (RI)
>
> 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).
Paris Paraskeva
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...@googlegroups.com
[mailto:Php-Object...@googlegroups.com] On Behalf Of Joel
Sent: Tuesday, April 24, 2007 5:44 AM
To: Php Object Generator
regards,
joel
__________ NOD32 2213 (20070423) Information __________
andy law (RI)
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.
Crispy
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.
Paris Paraskeva
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,
Websites in DreamWeaver
Later,
Andy
-------------
Yada, yada, yada...
__________ NOD32 2216 (20070424) Information __________
cvokk
> 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)
function __autoload($className){
$classPath['AdminUser'] = 'E:/newShop/app/scripts/pogobjects/
class.adminuser.php';
$classPath['AreaHistory'] = 'E:/newShop/app/scripts/classes/history/
AreaHistory.php';
$classPath['AuthorMenu'] = 'E:/newShop/app/scripts/classes/menu/
AuthorMenu.php';
$classPath['BaseTemplate'] = 'E:/newShop/app/scripts/classes/Template/
BaseTemplate.php';
if (!file_exists ($classPath[$className])) {
return eval ("class $className {" .
" function $className () {" .
" throw new Exception ();" .
" }" .
"}");
}
require_once($classPath[$className]);
}
I use Eclipse for everything, php, html, css.
Joel
website (http://beta.phpobjectgenerator.com)
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
Joel
- 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
Paris Paraskeva
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.
Regards,
Paris Paraskeva
Joel
- 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/thread/7752df410837293c
- 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
Paris Paraskeva
I think I will move to PHP 5 objects in the coming projects and see how
things go.
Even thought I have lots of objects relating to each other I opted to go
along without using pog relations since they are not helping a lot.
I have e.g. content types that need to relate with most of my objects, i.e.
image, document, meta_tags, video, contact, category. i.e an article object
will have its usual fields, but if its going to have
images,documents,metatags,category related to it the these objects are
generated with field type=article and id=article id so i can fetch the
images for this article using a normal get list filtering type=article and
id=articleid.
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...@googlegroups.com
[mailto:Php-Object...@googlegroups.com] On Behalf Of Joel
Sent: Wednesday, June 13, 2007 9:47 AM
To: Php Object Generator
regards
__________ NOD32 2325 (20070612) Information __________
andy law (RI)
> More improvements:
>
> - all create tables now have 'engine=myisam' in case the
> system is not configured for myisam by default.
With an option to choose a different engine if you want to ?