RE: beans and JSPs and stuff... -- JAVA400-L

>No they don't!  Not if you're using stylesheets and SSI.  Then you can just
>change HTML files just as you would JSPs.  Move the SSI include around on
>the page and it moves the dynamic content.  Change the stylesheet to change
>the look. 
----------
Not if there's any HTML in the SSI, Brad.  Unless the SSI is returning pure 
data, there is some formatting.  Now, if you've done some VERY astute 
programming in your SSI and it uses inline styles that are defined by the style 
sheet, then you may be able to get around some of the problem.  Or if your SSI 
accepts style parameters.  In that case, an SSI as you've presented it can 
indeed act a lot like a JSP widget.  But that's a lot of programming.

Here's an example.  To establish an editable table on my JSP, I do the 
following:

Servlet:
--------
ServerFactory factory = new ServerFactory();
Server server = factory.getServer("SERVERID");
DataTable table = new DataTable(server);
table.load();
session.putValue("widget", new DataTableWidget(table));

JSP:
----
<HTML>
<HEAD><TITLE>My Data Table</TITLE></HEAD>
<BEAN name="widget" type="DataTableWidget"></BEAN>
<BODY>
<%= widget %>
</BODY>
</HTML>

That's it.  But, let's say I want a new style.  I do something like this before 
displaying the widget:

<% widget.setStyle(TABLESTYLE); %>

The widget now will use the style TABLESTYLE, which I can define in my style 
sheet.

How would you do it with an SSI?  How would you define the fonts in your 
headings?  Or the fact that you want errors to appear as white letters on a 
read background?  With an object-based language like Java, I have much more 
flexibility in adding methods as required to extend the capabilities of my 
widgets and expose those methods to the JSP designer.  How will you do the same 
thing with an SSI?



>> The only way around this is to write a CGI program that in 
>> essence reads a specialized HTML page and plugs in your 
>> dynamic content wherever it's needed.
-------
>No it's not Joe.  I know I show my ignorance with Java and OO often, but
>this statement tells me that you probably haven't done quite as much CGI
>programming as I.  But then again, that's your "argument" for JSPs.  You
>don't need to.  But, still, my point stays.  
-------
Okay, show me how to do what I just did with an SSI.  Then we can give the list 
readers two different approaches.  In fact, I would go so far as to say we 
ought to build a library of these things.  I'd be happy to host them on 
Java400.net as soon as I get it running on my AS/400.



>JSPs are compiled by the server before they are run, unless that has
>suddenly changed and I missed the RFC.  I would also think that there is
>more room for typos causing runtime syntax errors to say the least.
--------
"Before" is the key word.  As in anytime before.  And only once.  After I call 
a JSP and it is compiled, any further invocations of the JSP use the already 
compiled object.  Hence the idea of preloading JSPs at webserver startup.

Typos?  Look how simple my syntax is above.  Sheesh.  You edit it, make a 
change, and hit the refresh button on your browser to test it.  Once tested, 
how are you going to get typos?  Done corectly, JSPs are no more susceptible to 
typos than if you key in the wrong name for your SSI.


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---