Re: [Myghty-users] xml and myghty

[David G. <dg...@sp...>]

Thanks, Mike. Your explanations are quite detailed, and I really 
appreciate that. I think I understand what you are saying. And, 
thankfully, it more-or-less confirms how I had been doing things (using 
the "mapper" approach) - except, rather than using a list for the "Form" 
elements, I was using a call-back technique (thus avoiding the form 
element objects themselves). I'm going to re-examine....

David

michael bayer wrote:
> 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
> 
>