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

Thanks in advance for your suggestion(s)

Regards,

The POG Team

I do have a few suggestions:

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

On 1/19/07, Joel <joel...@gmail.com> wrote:

Add more powerful querying between two objects...

If by example i need to join objects ... example:

select * FROM user as t1, photo as t2 WHERE t1.userId=t2.userId AND
t1.type=normal AND  t2.type=jpg

I dream big. I'm sure these would take a while...

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.

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

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.

Regards,

Paris Paraskeva
Managing Director
M.E. & E. UnitedWorx 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.

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.

Thanks,
Brian

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?

Cheers

Lumsden

do you mean something like the @link? http://
www.phpobjectgenerator.com/plog/tutorials/40/using-the-code-link

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:

Couldn't find "modify table" but clicked "modify object" (which I
assume is what you meant) and found that did exactly what I wanted.

Again many thanks.

Cheers

Lumsden

Have POG output a DOMDocument XML document based on your results? :)

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: