Hi All,
I think this thread exposes a couple of interesting "generic" issue
struggling to be exposed and defined :
Are the beans used in JSP pages meant to be "JSP beans" (ie. part of the
"view" portion the model-view-controller idiom), or are they meant to be
generic classes, not aware that they are being used in JSP (which would
make them part of the "model" in MVC).
Now, I'm going out on a bit of limb here, as I don't completely
understand the JavaBean architecture, so please correct me if I'm
wrong......||:]
I believe that the initial "JavaBean" architecture was designed for
building visual components for building user interfaces in IDE's. These
beans ARE aware where they are being used and should be. They have
clearly defined methods to interact with their container or context and
each other (infobus, activation framework ?). They can also register
themselves to react to the types of events that can be generated in the
GUI environment.
Similarly, this basic architecture has been adapted for Enterprise
JavaBeans, to create related component architecture for server-side
distributed business objects. There are interfaces to participate in
the various types of events such as transactions, loading, persistance
etc. Point is, these components know that they are EJB and are provided
with the tools to properly function in environment.
So, why not have another related type of JavaBean that is designed for
use in JSP ? Yes, this ties the class to being used in JSP, but is that
necessairly wrong ? The work it does has to be implemented somewhere,
the question is where is appropriate. If the system you are building
isn't suited to the scriptlet implementation, then you need to package
this functionality in the bean. JSP aware beans could then be able to
register themselves for various JSP events such processRequest/PageLoad,
SessionStart, SessionEnd.
I firmly believe your "model" classes should not be tied to a particular
presentation format (JSP, GUI, ??). But remember, this is just a class,
not a bean. This "model" class can be composited into, or inherited
from, in a JSP-aware bean that handles creating a HTML-(XML) based view
of that model.
Does any of this make any sense ?
Thanks
Drew
> -----Original Message-----
> From: h wulfson [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, 7 May 1999 10:32
> To: [EMAIL PROTECTED]
> Subject: Re: Pagelets Proposal
>
> I like this idea a lot. It helps to have a page-level
> component in which certain events trigger methods at
> various times in the request-response loop. This idea
> is somewhat like the "components" in WebObjects. Every
> template is bound to a component class, and all the
> components have a common superclass.
>
> -Harris
>
>
> --- James Klicman <[EMAIL PROTECTED]> wrote:
>
> > The key benefits of Pagelets would be:
> >
> > * Having a non-intrusive interface that JSP beans
> > can optionally
> > implement.
> > * Ability to create Servlet and JSP aware beans.
> > * Beans that can cleanup after itself.
> > * Pagelets would be thread-safe since a Pagelet
> > can only be
> > associated with one page at a time.
> > * A place to put processRequest
> >
> >
> > Here is what the Pagelet interface can look like:
> > - - - - - - - - - - - - - - - - - - - - - - - - - -
> > - - - - - - - - - -
> > - - - -
> > package javax.servlet.jsp;
> >
> > public interface Pagelet {
> >
> > /**
> > * Initializes the pagelet. Pagelets have a
> > lifespan of page.
> > * destroy() is called at the end of
> > _jspService.
> > */
> > public void init(PageContext pageContext);
> >
> > /**
> > * <p>This method gives the pagelet an
> > opportunity
> > * to clean up any resources that are being
> > held (for example,
> > * jdbc connections)
> > */
> > public void destroy();
> >
> >
> > /**
> > * Backwards compatibility, init(PageContext
> > pageContext) would
> > * replace it.
> > *
> > * @deprecated
> > */
> > public void
> > processRequest(HttpServletRequest request);
> > }
> > - - - - - - - - - - - - - - - - - - - - - - - - - -
> > - - - - - - - - - -
> > - - - -
> >
> >
> > Here are Pagelets in action:
> > - - - - - - - - - - - - - - - - - - - - - - - - - -
> > - - - - - - - - - -
> > - - - -
> > <jsp:useBean id="jdbcConnection" scope="page"
> > class="pagelets.JdbcConnection"/>
> > <jsp:useBean id="allUsers" scope="page"
> > class="pagelets.AllUsers"/>
> > <jsp:useBean id="allGroups" scope="page"
> > class="pagelets.AllGroups"/>
> >
> > <html>
> > All Users:<br>
> > <ol>
> > <%
> > String[] users = allUsers.getUsers();
> > for (int i = 0; i < users.length; i++) {
> > %>
> > <li> <%= users[i] %>
> > <%
> > }
> > %>
> > </ol>
> > <p>
> >
> > All Groups:<br>
> > <ol>
> > <%
> > String[] groups = allGroups.getGroups();
> > for (int i = 0; i < groups.length; i++) {
> > %>
> > <li> <%= groups[i] %>
> > <%
> > }
> > %>
> > </ol>
> >
> > </html>
> > - - - - - - - - - - - - - - - - - - - - - - - - - -
> > - - - - - - - - - -
> > - - - -
> >
> > How Pagelets benefit us in this example would be
> > automatic clean up of
> > the JDBC connection and the ability to invisibly
> > share the connection.
> > The Pagelet jdbcConnection would have its destroy()
> > method called at
> > the end of _jspService and would then close the
> > connection. Meanwhile
> > both allUsers and allGroups could have used the
> > database connection
> > that jdbcConnection created and made available
> > through the
> > request.setAttribute().
> >
> >
> > I think Pagelets can consolidate and provide some
> > features that people
> > have been asking for on the JSP list. One being
> > processRequest
> > functionality and another being Thread-Safe beans,
> > and my personal
> > favorite automatic bean cleanup.
> >
> > -James Klicman
> >
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> ======================================================================
> =====
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff JSP-INTEREST". For general help, send email
> to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
