hey howard -
again the code i wrote for this stuff is 2.5+ years old and as such my
recollection is a bit fuzzy. the site i'm talking about is javashop.sun.com
(the backend to many try and low price-point uy products: solaris 8,
star office, etc ... rather heavy volume sites).
the scheme i provided describes a manner to generate a form either
for the initial time or a return visit (eg an error has been detected).
the form processing side of the puzzle was handled, in my case, by
an ActionManager class which acted as a "request-to-logic" traffic
cop and delegated the request handling the the appropriate module.
a sprinkled in some "current/previous/next" page markers in the flow
and recovering from a data error was actually pretty trivial and, for
the most part, plug and play for new pages/logic/etc.
you probably get the idea now that my ActionManager was a thin
delegator to *lots* of logic ... which could be chained ... and moved
the current/previous/next doc marker as approriate. as such this
code is rather app specific. right before the final request handler
returned to the client with a reply a small piece of code would
route to the target page (next) on the server side (we called this
server-side redirect back in the day: jdk 1.1.3 and we needed all
the peformance boosts we could get our mits on) and possibly
invoke the target ActionManager logic again. to pull this off we
rolled our own servlet forward (and include) but when those features
appeared on the scene we moved over to them quite nicely.
lastly, *all* of the above was managed via dynamically read
local property file (ie i could change the entire site behaviour
simply by editing a prop file and wating for the next read cycle).
another strategy we had in place was a "page requires these objects"
in the session mapping, again in prop files, in order to proceed,
rollback, etc. these ideas can be brought to the 21st century,
wow ... first time i ever said that about a 2.5 year old app ...
by going xml/http from a central prop server protected with some
security constructs.
btw, a former partner-in-crime on this project saw my posting and
may have more to add as he helped flesh this scheme out quite
nicely. these days i work on web aware apps that aren't necessarily
html bound (breaking the four walls of the browser so to speack). much
of the logic i've layed out still applies and as such i'm still working this
issue but in a client rendering agnostic manner. as such, i'm quite open
to suggestions/experiences on this thread.
hope this helps,
- james
Howard Lee wrote:
> Thanks James, but how would you do data validation of each field? I want the
> program to return back to the form page if there is any error with
> appropriate error message for each field. Again thanks.
>
> howard
>
> -----Original Message-----
> From: A mailing list for discussion about Sun Microsystem's Java Servlet
> API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of James
> Todd
> Sent: Tuesday, June 13, 2000 10:41 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Form Generator
>
> this is trivial. not sure about available software but what i've done in
> the past is:
>
> create a "FormManager" which takes a series of attributes and
> generates the appropriate html form
>
> codify the form data as property attributes following some
> conventions
>
> read the form data via a "PropertyManager", perferably one
> which will refresh when the property data changes
>
> the FormManager can even update the form field with the
> appropriate session data for smart defaults
>
> supporting all html forms and associated attributes is really
> pretty simple and can be achieved using seven or so standard
> attributes
>
> i did this nearly three years ago. if i was to take a stab at it today
> i'd consider some form of xml data (vs property files) and pull
> the data over http from a centralized "form master repository"
> (vs read local file). xul looks interesting to me but i've opted for
> a simplier route as it is a bit heavier then i had hoped for ... imho.
>
> hope this helps,
>
> - james
>
> Howard Lee wrote:
>
> > Hi,
> >
> > Has anyone worked on a form generator? I'm trying to write a program where
> I
> > define fields (whether it's a textfield, or drop down box) and a servlet
> or
> > JSP generates a form? Can this be possible? Any resources out there? Thank
> > you very much!
> >
> > howard
> >
> >
> ___________________________________________________________________________
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html