Re: [Myghty-users] xml and myghty
Brought to you by:
zzzeek
From: michael b. <mi...@my...> - 2004-12-12 21:02:00
|
hey david - with the XML->something issue, I am a big fan of defining the conceptual thing you are ultimately dealing with in some kind of object model. this means that if you are going from XML->HTML form, you have a set of "form" objects in the middle that serve both as a friendly place to receive XML instructions, and an easily iterated collection when serving up HTML rendering instructions. as far as what that object model looks like for HTML forms, there just happens to be a great beginning to one in the shopping cart demo. Generating HTML from lots of small pieces with their own properties is the primary strength of Myghty which I have not seen in too many other compiled server page architectures (except Mason of course). In that demo, there is a module form.py that contains a hierarchy of form and form element classes. and there also is a Myghty component called "forms.myc" which contains form element methods which are able to read instructions from those element classes as to what the names and values are for those fields, as well as some data-oriented parameters. There is even a super rudimental "User" object defined for the shopping cart. the Form object is also able to do a very simple "reflection" between its own fields and a data object such as a User or Address object. the shopping cart forms model puts the responsibility of the HTML layout itself into some other Myghty template...that is a product of my usual project experience where HTML designers, or even myself, are designing forms by hand, and the layout of those forms is usually way too custom for them to be encoded in a simple data format. so the one extra thing the model needs to totally generate forms are some "layout" properties in the form and form element classes, and some more Myghty templates that render HTML forms by iterating through the form element objects and relating them to individual Myghty form element methods. as far as the XML, you can have your Form objects store a reference to, or just read the properties from, their corresponding DOM elements directly (this can be called "active record"), or have another object that reads the XML and creates a Form structure (a "mapper" approach) something like this: # make new form object form = Form() # get a dom object dom = Dom('myfile.xml') # loop through DOM and append new FormElements to the form for domelement in dom.elements('formelement'): form.append( FormElement(domelement.attribute('name'), domelement.attribute('size'), domelement.attribute('description'), domelement.attribute('isrequired'), # ... other properties needed in form fields ) ) the "mapper" approach is good for when your data object and your target object dont necessarily look that similar to each other, or you want to be able to easily vary the structure of each one independently of each other. you would also need to somehow tie the individual fields in your form to fields inside your User object. probably through a keyword in each XML field definition that maps each HTML field to an attribute in your User object. if the mapping is simple enough, you could use a straight "reflective" approach to read the fields from the User object into the form. an important point is, the whole XML/User/Form object side of this has no knowledge whatsoever of Myghty. Which is also handy since you can unit test the whole thing from the command line and see how well its working. Its the final bit, the module component, that knows about everything. a module component would serve as the final tying together of all the pieces... it would be a single module at the beginning of the process, takes the URI information in, locates the correct XML document and user info from the database, then calls the appropriate mapper to generate a form object from it, then connects the User data into the form via another mapper or reflection method within the form object, then sends that form object off to the appropriate myghty template file for display. so hows that ? On Dec 12, 2004, at 2:11 PM, David Geller wrote: > Hi, > > I have been wondering how to incorporate things such as xml processing > with myghty. > > I am talking about a mod_python application to dynamically merge two > elements: an xml file describing a form, including a description of > various form elements and their parameters, and user data obtained > from a database. When called with a specific uri, the app will grab > user data from a database, read an xml file (or other descriptive > file), process that file, and generate an html form, incorporating the > user data into the fields. > > Any ideas on how best to architect this in a "myghty" way? Especially > in terms of "module components".... > > I could tell you have I have done it, but am curious of there is a > clean way to seperate out the xml processing, yet call myghty when > needed to produce form elements one by one, retaining all the > flexibility that myghty templates (with inheritance) have at the page > level. > > Thanks, if you want to tackle this! > > David > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Myghty-users mailing list > Myg...@li... > https://lists.sourceforge.net/lists/listinfo/myghty-users |