on 1/10/2001 1:29 PM, "Paul O'Leary" <[EMAIL PROTECTED]> wrote:
> My initial comment on this is that I think this idea is going 100% in the
> right direction.
> The problem here, as I understand it, is to begin to break down the still
> too-strict coupling (in Turbine) between display and business logic. That
> is, the current framework of Turbine encourages code to be organized around
> Actions and Screens - which are tied directly to templated HTML screens -
> instead of around the 'logical' business objects of an application. Another
> way of putting this: you want your app design to be organized around your
> business objects (at least logically), not spread out through screens and
> actions.
I would argue that to say that my Pull document suggests that Screens (with
respect to the application itself) are not needed any longer and that
Actions are still necessary. I still believe that it will be difficult to
entirely remove Actions and that Actions are not entirely a "bad thing" as
you can still move form fields around (even between pages) without having to
rely on modifying the correctly written Action class. :-)
> Let me expand/modify the xml definition you suggest and try a few other
> ideas on you. Hopefully I can do this without an avalanche of details.
>
> <dialog id="issue_attrib_defn">
> <object type="ScarabIssueAttributeValue" id="att"/>
> <panel>
> <InputField name="option_id" id="o" type="int" obj_map="att"
> map_to="OptionId">
> <Rule mask="[0..9] onError="-1" />
> </InputField>
> <InputField name="value" id="v" type="String" obj_map="att"
> map_to="Value">
> <Rule max_length="255" />
> </InputField>
> </panel>
> </dialog>
>
> My suggestion here is that the xml defines not only the info available to a
> template designer but also how fields from a form should be transformed and
> mapped back to objects in the applications data model. In other words the
> xml - the metadata - defines what dynamic information is available to the
> template designer and how it maps into the app's business logic.
> It becomes possible then to write or generate Actions and Screens (the
> Turbine objects) that can interpret the xml and generate the dynamic data to
> be put into the context for the template designer and take form data,
> process it and map it correctly into the data objects in the system.
Right. I think we are all saying the same thing and are all on the same
page. However, again, I think the need to write individual Screens has been
removed. In fact, I'm proving this by attempting to do Scarab without having
*any* specific Screen classes at all other than at most a Default.java
Screen.
> Having an app described this way would have endless benfits, not the least
> of which is that it becomes much easier to modify. If you want to break the
> functionality of one screen into two the app designer modifies the xml and
> the template designer re-writes the affected screen.
Yes, that is *exactly* the direction we want to go in. Wanna help make it a
reality? :-)
-jon
--
Honk if you love peace and quiet.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
