could brian could you recommend a good book on java servlets. aside from
the online documentation which is a hell to read online and a pain to
print. thanks. 

On Sun, 30 Jul 2000, Jeff Gutierrez wrote:

> 
> Hi Brian,
> 
> Pretty interesting...
> 
> But there's a caveat in putting everything in the database..  A few years
> back, DB companies were evengelizing that the DB should be the repository
> of all information presented in the web page.. Pretty interesting piece
> but early adoptors soon learned that doing so required tons of resources
> from the database, which made then slow as hell.  On example of this is
> Informix' Web DataBlade.  
> 
> This is the very reason why application servers came about.. so there can
> be separation of presentation generation (JSP, ASP, PHP) from the business
> logic, and the database.  
> 
> An alternative that I can suggest to Orly is JavaServer Pages (JSP) Custom
> Tags. JSP custome tags are actually vanilla JavaBeans that are called by
> the JSP engine whenever encountered.  Here's a possible JSP tag lib:
> 
> <XX_FORM name="pangalan" sqlview="SELECT first_name, last_name">
>   <XX_INPUT type="text" displayname="First Name" sqlfield="first_name"/>
>   <XX_INPUT type="text" displayname="Last Name" sqlfield="last_name"/>
> </XX_FORM>
> 
> Following the JSP tab lib API, your XX_FORM, and XX_INPUT JavaBeans can
> get the data from the DB then from the params, generate the form elements
> within the bean.
> 
> HTH
> 
> jeff --
> 
> On Sun, 30 Jul 2000 [EMAIL PROTECTED] wrote:
> 
> # 
> # Orlando Andico writes:
> # > hello all,
> # > 
> # > i'm pretty sick of writing html forms (big form, updates or inserts into
> # > database table). so i've decided to write a dynamic form generator: you
> # > give it some input (an XML file describing the form [title, colors,
> # > fonts], DBI connection DSN, input attributes [type, validation rule, LOV
> # > source if it's multiple choice, etc] etc) and it spits out the HTML if
> # > there's no input, and processes the input if there is.
> # 
> # Hehe, I wouldn't even bother with an XML file.
> # 
> # Since you already have a database at your disposal, why not store the
> # display and input options (if they're not "default") in database tables?
> # That way, you don't have to struggle with an XML parser and end users don't
> # have to write XML. That way the specs for the display (color, font,
> # visibility, widget placement, etc.) and input options (digits only,
> # multiple choice options, pick list SELECT DISTINCT somefield FROM
> # someothertable, etc.) would be available to other client applications
> # connecting to the database directly (e.g. those that would not have access
> # to the XML file), and use that information to render the data entry screens
> # correctly.
> # 
> # Then you could use the form generator to generate a form to modify the
> # display options for the form generator. :-) 
> # 
> # > it will be able to process multi-page forms (with Prev, Next buttons) via
> # > a <Page></Page> tag, and do basic DBI error recovery. I've done a cursory
> # > search of freshmeat and found nothing that has this functionality.
> # 
> # You could then extend this by defining a couple of tables to store state
> # machines describing the logic for your supported transactions, and you'd
> # have a fully customizable web-based DB application builder.
> #  
> # > However, I'd like to know if anyone of the list is aware of a similar
> # > product (Oracle WebDB has a similar philosophy but different
> # > implementation and is far more general). because i dont want to reinvent
> # > the wheel.
> # 
> # I believe there are a couple of commercial products that work as I
> # described. If I'm not mistaken, that's how Oracle's WebDB works too.
> # AOLserver 2.3.3 has a quick-and-dirty DB form template that works like
> # that. 
> # 
> # Then, if you wanted to pad your resume with another industry buzzword, you
> # could just add options to export the various datamodels into XML DTDs.
> # 
> # > anyway below is a sample config file that describes a form (dont worry
> # > there is no code or parser yet, im just writing out the config so i know
> # > what features i must implement..)
> # 
> # Just some ideas and abstractions you might want to consider. And, yes, I
> # have built (and helped others build) quite similar systems before, so it is
> # a workable model.
> # 
> # Well, I should stop before I take all the fun out of it for you. The easy
> # first part should be doable within a day or two if you're using a scripting
> # language, but the logic really is no different whether you're using Perl or
> # Java. 
> # 
> # Happy coding! :-)
> # 
> # Brian
> # --
> # Brian Baquiran <[EMAIL PROTECTED]>
> # http://www.baquiran.com/  AIM: bbaquiran 
> # Work: +63(2)7182222       Home: +63(2) 9227123
> # 
> # I'm smarter than average. Therefore, average, to me, seems kind of stupid. 
> # People weren't purposely being stupid. It just came naturally.
> #                               -- Bruce "Tog" Toganazzini
> # -
> # Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
> # To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]
> # 
> 
> 
> Jeff Gutierrez
> ---
> http://www.gra.ph
> graPH - The substance that makes techies tick!
> 
> 
> -
> Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
> To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]
> 

 
---------------------
[EMAIL PROTECTED]
 
... I think I'd better go back to my DESK and toy with a few common
MISAPPREHENSIONS ...
 

-
Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]

Reply via email to