You can check out FunFormKit as a way to build forms on the fly.
Not sure about the 'best practice' but:
I am designing a similar project where I read some meta-data (from the
database directly) and use that to build up a list of datatypes that
'can' be worked with. Then I read a prefernces table that tells me
about things like the field labels and should be edited. Then FFK and
cheetah build the form on the fly.
To render a form I use something like:
<tr>
#for $field in $fields::
<td>$field.label</td>
#end
#for $row in $ResultSet:
<tr>
#for $field in $row:
<td>$field.value</td>
#end
</tr>
#end
I started playing with a better idea using MiddleKit or SQLOBjects to
render the UI. Rather then build a pref table I would like to have one
middleware object per customer type. The middle object should know how
to render the UI (Put out a field dict w/ labels, datatype, permissions
etc...) as well as how to talk to the backend (DB_API)
This way I would just have to load this object and make the same calls
against it for each page.
I also played with differnt cheetah templates per account, but I tried
putting them in a 'templates' module and managing them via the
filesystem. That worked well, but you wind up with lots of template
intances per Application.
-Aaron
Michael Engelhart wrote:
> Hey all,
>
> Quick question that I'm hoping someone else has figured out :-)
>
> I have a customer management system that allows multiple clients to
> have their own lists of customers which are stored in an LDAP
> directory. When a client logs in a basic set of preferences is
> loaded into that users session from a database. This works fine
> except now certain clients need completely different fields in their
> customer add/search forms. I'm using a Webware/Cheetah solution and
> am trying to figure out the best way to handle this extra 'variable'
> data that needs to be added into the search form.
>
> For example, one client is an auto dealer and they need 7 or 8 fields
> that aren't part of the usual name, address, city, state zip, email,
> etc. that most of the clients use. They need transaction type (new
> car, used car, etc) and financing information (30, 60, 72 month lease
> or sale), transaction date, vehicle make, vehicle model, vehicle year
> and sales reps name. I have new customers coming on that are real
> estate brokers, insurance agents, etc. each with their own sets of
> fields they need to track.
>
> As a quick solution, I created a Cheetah template that I attached to
> the clients Preference object as a text field. then I "include" that
> field into the search/add customer form templates. While this works
> as quick solution, it's very unwieldy when it comes to making changes
> to the preferences object. The preference object is a pickled Python
> object that I read in upon login.
>
> Any ideas would be greatly appreciated. one thought was to build a
> user interface to the per client templates but that seems like a lot
> of work since I don't necessary know what types of fields are going to
> be needed in the future.
>
> Thanks for any help
>
> Mike
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Tablet PC. Does your code think in
> ink? You could win a Tablet PC. Get a free Tablet PC hat just for
> playing. What are you waiting for?
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> https://lists.sourceforge.net/lists/listinfo/webware-discuss
|