This is the tentative feature set that we're looking at for 3.0. Please feel free to use this thread to suggest a feature, that we may have forgotten about/you feel should make it for 3.0:
Here's what we have so far (may be a bit ambitious)
GENERATOR -> address performance issues w/ and w/o encoding -> plugin architecture + sample plugins -> allow encoding on a field level (instead of project level) -> simple data integrity checks (specify fields that must be != '<empty>') -> code cleanup -> compliance with strict mode in PHP5/MySQL5
FIXES -> getlist must return all records if no conditions are supplied
SETUP -> plugin management (?) -> allow mangement of children/sibling via the interface
1.) Boolean Types Since you are now supporting only MySQL databases, could you add native support to BOOL types? Such that they are handled as true / false values rather than 0 / 1? You may need to allow both to keep backward compatibility. Currently to use BOOL types you have to specify "OTHER..." for the field type dropdown and type "BOOL" into the resulting textbox.
2.) Default Values Allow entry of an initial (default) value for fields. I notice the need for this the most when I am adding a new field to an existing object that already has records in the db. After adding the new field, it is set to null for all the existing records. I must write an update script to initialize that value (which is really not that hard, but a minor annoyance).
When you implement fields that are required, you may encounter the need for a default value. Consider the scenario where you have existing records for an object and you add a field to that object that is not allowed to be empty. What value will the existing records have for that field? If some value is not assigned to them, they break the constraint that the field is not allowed to be empty.
-Chris
-- Chris Edwards
"And whatsoever ye do, do it heartily, as to the Lord, and not unto men;" - Col 3:23
> This is the tentative feature set that we're looking at for 3.0. Please > feel free to use this thread to suggest a feature, that we may have > forgotten about/you feel should make it for 3.0:
> Here's what we have so far (may be a bit ambitious)
> GENERATOR > -> address performance issues w/ and w/o encoding > -> plugin architecture + sample plugins > -> allow encoding on a field level (instead of project level) > -> simple data integrity checks (specify fields that must be != > '<empty>') > -> code cleanup > -> compliance with strict mode in PHP5/MySQL5
> FIXES > -> getlist must return all records if no conditions are supplied
> SETUP > -> plugin management (?) > -> allow mangement of children/sibling via the interface
1) Customizable local generators Have the local generators save the generated files directly into a specified directory.
2) Setup integrates the generator Jump from a set up tool to a local generator, make a new object, object is saved to a specified directory, and go back to the setup which checks all the objects again and then lets you continue managing them.
What I would like to be able to do is customise the naming convention for the id field. Currently it's table name + "id" but I would like table name + underscore + id so the items table goes from itemsid to items_id.
I know someone will say just search and replace automatically but then why have a car if you have legs, it just makes life easier.
Well backwards compatibility is a must for anyone I think.
So POG 3 should abide by that law. If any feature is added like changing the naming convention and such will break our code and I personally would not like to see any feature which will make pog not backwards compatible with existing versions.
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 lumsden Sent: Friday, January 26, 2007 2:56 PM To: Php Object Generator Subject: [Php-Object-Generator:914] Re: suggest a feature for 3.0
Top of the day to you, squire !!
What I would like to be able to do is customise the naming convention for the id field. Currently it's table name + "id" but I would like table name + underscore + id so the items table goes from itemsid to items_id.
I know someone will say just search and replace automatically but then why have a car if you have legs, it just makes life easier.
I thank you.
Lumsden
__________ NOD32 2008 (20070125) Information __________
I would like to see transactions for PDO and customizable table, index, and key naming. I'm new to POG so I'm sure I'll think of more once I get a little more aquaitned.
This might be quite tricky to do but quite helpful to me at least.
I create some quite long winded tables. I often edit them and instead of entering the whole table again, it would be good if POG could read the original statement it produced, create all the attributes and set the types. Then I could simply tinker with a couple of settings and press Generate.
Hardly mission critical but could be useful. Might also be a start on the road to reverse engineering?
Or pressing modify table from within setup should also do the same thing...although there are some issues with very long tables (thus url) and IE. Ffox should be able to handle it though..
Joel
On Jan 29, 2:21 pm, "lumsden" <a...@yorweb.co.uk> wrote:
> This might be quite tricky to do but quite helpful to me at least.
> I create some quite long winded tables. I often edit them and instead > of entering the whole table again, it would be good if POG could read > the original statement it produced, create all the attributes and set > the types. Then I could simply tinker with a couple of settings and > press Generate.
> Hardly mission critical but could be useful. Might also be a start on > the road to reverse engineering?
A way that an object can own an object and still have a list of other objects?
ie: a user owns a list of contacts, but the list of contact's are user objects, so user would be a parent and a sibling (parent differentiates who owns the list) {Owner} ?
I agree with Eidolon. It would be useful to have an owner relationship where:
a) the owned objects' type could be any other object type including the same as the owner object b) the owned objects' type could be aliased to something relevant to the type of ownership ( like Eidolon's example of a contact list of users )
I'm not sure if this is possible or how it would be done, but it would be an awesome built in feature.
On Jan 31, 2:47 am, "Eidolon" <eido...@idealsound.ca> wrote:
> A way that an object can own an object and still have a list of other > objects?
> ie: a user owns a list of contacts, but the list of contact's are user > objects, so user would be a parent and a sibling (parent > differentiates who owns the list) > {Owner} ?
On Jan 30, 10:54 pm, "Eidolon" <eido...@idealsound.ca> wrote:
> Have POG output a DOMDocument XML document based on your results? :)
Hi Eldolon,
Joel and I talked about this a couple of years ago, but it wasn't smooth to implement at that time (and not totally necessary for what we were doing), however, I think this would be possible (and, I think, relatively simple) as a plug-in extension - and would be terribly useful at times.
Since XML is "supported" with PHP 5 - the plugin model would be the right fit for the solution too.
Hi, I feel a bit confused, or perhaps extra-slow today, so I'm not following quite what you are getting at, but is this following discussion along the lines of what you are talking about? "Foreign key references key in same table?" http://groups.google.com/group/Php-Object-Generator/browse_thread/thr...
On Jan 31, 10:09 am, "arhodes" <alice.rho...@gmail.com> wrote:
> I agree with Eidolon. It would be useful to have an owner relationship
SO useful, I've been coding that non-stop since I've made my post, I'll classify it outside of my framework and post it when I get it working well and hopefully the community can help me improve on it..
Right now it takes a POG or an array of POGS as the first argument, boolean to recurse through parent/child/sibling/owner (hacked in, based on the column being called owner_fieldname), and a whitelist of fields, which will be an array of arrays so that you can filter what columns you need (ie, array("user" => array("username","password"), details => array("email"))
:)
On Jan 31, 7:06 pm, "Crispy" <marksle...@gmail.com> wrote:
> On Jan 30, 10:54 pm, "Eidolon" <eido...@idealsound.ca> wrote:
> > Have POG output a DOMDocument XML document based on your results? :)
> Hi Eldolon,
> Joel and I talked about this a couple of years ago, but it wasn't > smooth to implement at that time (and not totally necessary for what > we were doing), however, I think this would be possible (and, I think, > relatively simple) as a plug-in extension - and would be terribly > useful at times.
> Since XML is "supported" with PHP 5 - the plugin model would be the > right fit for the solution too.
> SO useful, I've been coding that non-stop since I've made my post, > I'll classify it outside of my framework and post it when I get it > working well and hopefully the community can help me improve on it..
> Right now it takes a POG or an array of POGS as the first argument, > boolean to recurse through parent/child/sibling/owner (hacked in, > based on the column being called owner_fieldname), and a whitelist of > fields, which will be an array of arrays so that you can filter what > columns you need (ie, array("user" => array("username","password"), > details => array("email"))
> :)
> On Jan 31, 7:06 pm, "Crispy" <marksle...@gmail.com> wrote:
> > On Jan 30, 10:54 pm, "Eidolon" <eido...@idealsound.ca> wrote:
> > > Have POG output a DOMDocument XML document based on your results? :)
> > Hi Eldolon,
> > Joel and I talked about this a couple of years ago, but it wasn't > > smooth to implement at that time (and not totally necessary for what > > we were doing), however, I think this would be possible (and, I think, > > relatively simple) as a plug-in extension - and would be terribly > > useful at times.
> > Since XML is "supported" with PHP 5 - the plugin model would be the > > right fit for the solution too.
as Mark mentioned, the plugin feature that we'll officially 'propose' in a few days, will, imho, work very nicely with custom code like yours Eidolon, and converting your final framework into a POG plugin should be quite straightforward.
There are a few ways to 'customize' the POG code - object inheritance, plugins, direct code modification..etc. While inheritance, direct code modification are currently being used by many developers, there is no real easy way to share functionality among different objects/projects/ developers. The plugin piece is meant for exactly this type of code, where the function(s) perform something that's not tied to the business logic, and can be shared among developers and objects.
We should be able to officially propose a plugin architecture for review/criticism in the coming days.
regards, Joel
On Feb 1, 2:08 am, "Eidolon" <eido...@idealsound.ca> wrote:
> On Feb 1, 2:03 am, "Eidolon" <eido...@idealsound.ca> wrote:
> > SO useful, I've been coding that non-stop since I've made my post, > > I'll classify it outside of my framework and post it when I get it > > working well and hopefully the community can help me improve on it..
> > Right now it takes a POG or an array of POGS as the first argument, > > boolean to recurse through parent/child/sibling/owner (hacked in, > > based on the column being called owner_fieldname), and a whitelist of > > fields, which will be an array of arrays so that you can filter what > > columns you need (ie, array("user" => array("username","password"), > > details => array("email"))
> > :)
> > On Jan 31, 7:06 pm, "Crispy" <marksle...@gmail.com> wrote:
> > > On Jan 30, 10:54 pm, "Eidolon" <eido...@idealsound.ca> wrote:
> > > > Have POG output a DOMDocument XML document based on your results? :)
> > > Hi Eldolon,
> > > Joel and I talked about this a couple of years ago, but it wasn't > > > smooth to implement at that time (and not totally necessary for what > > > we were doing), however, I think this would be possible (and, I think, > > > relatively simple) as a plug-in extension - and would be terribly > > > useful at times.
> > > Since XML is "supported" with PHP 5 - the plugin model would be the > > > right fit for the solution too.
> On Feb 1, 2:03 am, "Eidolon" <eido...@idealsound.ca> wrote:
> > SO useful, I've been coding that non-stop since I've made my post, > > I'll classify it outside of my framework and post it when I get it > > working well and hopefully the community can help me improve on it..
> > Right now it takes a POG or an array of POGS as the first argument, > > boolean to recurse through parent/child/sibling/owner (hacked in, > > based on the column being called owner_fieldname), and a whitelist of > > fields, which will be an array of arrays so that you can filter what > > columns you need (ie, array("user" => array("username","password"), > > details => array("email"))
> > :)
> > On Jan 31, 7:06 pm, "Crispy" <marksle...@gmail.com> wrote:
> > > On Jan 30, 10:54 pm, "Eidolon" <eido...@idealsound.ca> wrote:
> > > > Have POG output a DOMDocument XML document based on your results? :)
> > > Hi Eldolon,
> > > Joel and I talked about this a couple of years ago, but it wasn't > > > smooth to implement at that time (and not totally necessary for what > > > we were doing), however, I think this would be possible (and, I think, > > > relatively simple) as a plug-in extension - and would be terribly > > > useful at times.
> > > Since XML is "supported" with PHP 5 - the plugin model would be the > > > right fit for the solution too.
> > On Feb 1, 2:03 am, "Eidolon" <eido...@idealsound.ca> wrote:
> > > SO useful, I've been coding that non-stop since I've made my post, > > > I'll classify it outside of my framework and post it when I get it > > > working well and hopefully the community can help me improve on it..
> > > Right now it takes a POG or an array of POGS as the first argument, > > > boolean to recurse through parent/child/sibling/owner (hacked in, > > > based on the column being called owner_fieldname), and a whitelist of > > > fields, which will be an array of arrays so that you can filter what > > > columns you need (ie, array("user" => array("username","password"), > > > details => array("email"))
> > > :)
> > > On Jan 31, 7:06 pm, "Crispy" <marksle...@gmail.com> wrote:
> > > > On Jan 30, 10:54 pm, "Eidolon" <eido...@idealsound.ca> wrote:
> > > > > Have POG output a DOMDocument XML document based on your results? :)
> > > > Hi Eldolon,
> > > > Joel and I talked about this a couple of years ago, but it wasn't > > > > smooth to implement at that time (and not totally necessary for what > > > > we were doing), however, I think this would be possible (and, I think, > > > > relatively simple) as a plug-in extension - and would be terribly > > > > useful at times.
> > > > Since XML is "supported" with PHP 5 - the plugin model would be the > > > > right fit for the solution too.
Its name would be some standart name we choose and this class would be empty by default, so no change to working of existing objects at all. Class file would be included in every zip file.
The advantage I see - in PHP 5 functions you can force argument to be a POG object, for example: function someFunction(ParentPogClass $somePogObject){ ... code ...
}
You can add your own methods to all pog objects with ease ... What do you think about it?
> Its name would be some standart name we choose and this class would be > empty by default, so no change to working of existing objects at all. > Class file would be included in every zip file.
> The advantage I see - in PHP 5 functions you can force argument to be > a POG object, for example: > function someFunction(ParentPogClass $somePogObject){ > ... code ...}
> You can add your own methods to all pog objects with ease > ... > What do you think about it?
I'd like to make my tables in another tool so that i can set up default values and other stuff like extra indexes etc. Another thing might be to support innodb tables which is better for referential integrity and transactions.
love POG btw!
On 19 feb, 15:26, "Sorer" <vbu...@chello.sk> wrote:
> This is the tentative feature set that we're looking at for 3.0. Please > feel free to use this thread to suggest a feature, that we may have > forgotten about/you feel should make it for 3.0:
> Here's what we have so far (may be a bit ambitious)
> GENERATOR > -> address performance issues w/ and w/o encoding > -> plugin architecture + sample plugins > -> allow encoding on a field level (instead of project level) > -> simple data integrity checks (specify fields that must be != > '<empty>') > -> code cleanup > -> compliance with strict mode in PHP5/MySQL5
> FIXES > -> getlist must return all records if no conditions are supplied
> SETUP > -> plugin management (?) > -> allow mangement of children/sibling via the interface
