Very very interesting. Thank you very much, this is what i want.
One thing I don't understand: should UllFlowDoc and UllFlowValue be
the same table? why are they separated?


On 9 Ago, 23:15, klemens_u <[email protected]> wrote:
> Hi cosmy,
>
> Bernhard pointed out that we did something similar in ullright.
>
> The actual project site ishttp://www.ullright.org.
>
> We use such virtual tables especially for our workflow module
> "ullFlow".
>
> Have a look at the database 
> structure:http://trac.ullright.org/browser/trunk/plugins/ullFlowPlugin/doc/sche...
>
> The main points of interest are the definition of "virtual tables" in
> "UllFlowApp"
> and the definition of the virtual tables's columns in
> "UllFlowColumnConfig".
> The equivalent to rows is then stored in "UllFlowDoc", and the
> column's values in "UllFlowValue".
>
> You are also kindly invited to visit the backend of our demo
> installation:http://demo.ullright.org/ullAdmin(login with admin/test)
> In the section "Workflow" you'll find "Manage applications" and
> "Manage columns".
>
> From a technical point of view much logic resides in the "UllFlowDoc"
> model:http://trac.ullright.org/browser/trunk/plugins/ullFlowPlugin/lib/mode...
>
> We also have a powerful generator which dynamically builds a sfForm.
> Here's an frontend example of a form of such virtual 
> table:http://demo.ullright.org/ullFlow/create/app/purchase_request
>
> Klemens
>
> On Aug 9, 10:35 am, Bernhard Schussek <[email protected]> wrote:
>
>
>
> > Hi,
>
> > In my opinion you should really create a virtual schema as the previous
> > poster mentioned. Create one table "Table" that stores the custom tables,
> > one table "Field" for the field definitions (like display name, type,
> > default value etc.), one table "TableEntry" for the virtual objects and one
> > table "FieldValue" for the values of the virtual fields.
>
> > A colleague of mine did this in his open-source project "Ullright" which is
> > a available athttp://ull.at. I suggest to look at its source if you want to
> > know more.
>
> > Bernhard
> > --
> > Sent from my HTC Hero
>
> > 7. Aug 2009 11:56 vorm. schrieb am "cosmy" <[email protected]>:
>
> > Ok, i think it could be a solution but.. how do i manage the
> > persistence of this data?
> > In other words, how do i save the data of these forms in the database?
> > Maybe as an unique string in a specific table ( in example:
> > [attribute: value | attribute2: value2] ) ?
> > but how do i manage the queries? i have to use LIKE or regexp and it
> > will be very slow to get out data of a specific type of entry, won't
> > it?
>
> > Is there an api of symfony to manage this kind of things?
>
> > On 7 Ago, 08:22, Alan Bem <[email protected]> wrote: > You shouldn't change
> > database schema on "li...
>
> > > On Fri, Aug 7, 2009 at 5:50 AM, Alan Candido <[email protected]> wrote: > >
>
> > Hi, > > > I don't tried...
>
> > > > 2009/8/3 cosmy <[email protected]>
> > > > >> Hi all, > >>  I need to realize an application that let the
>
> > possibility to make > >> dynamic ...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"symfony users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/symfony-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to