On Wed, 12 May 1999, Drew Cox wrote:
> Hi Larry,
>
> Your comment below is interesting.....
>
> > We dont actually believe that "model 2" is the preferred model
> > for JSP usage, JSP's *do not* typically require Servlet
> "masters"
> > in order to create applications. Servlets (in our view) are an
> > abstraction of last resort, when JSPs alone cannot be used to
> > solve a problem.
>
> I agree that for some systems, the model 2 (user request -> servlet ->
> jsp -> response) approach may not be required and support for a complete
> and robust model 1 (user request -> jsp -> reponse) approach is an
> absolute neccessity.
>
> However, for a lot of other systems, the model 2 approach makes a lot of
> sense. I guess your comment above implies to me that the JSP team
> ("We") are favouring the model 1 design over model 2. I think it would
> be a terrible shame to ignore the requirements of the model 2 approach
> and it would probably encourage the use of non-standard templating
> implementations from the servlet camp.
>
> JSP strength is in it's application model flexibility and integration
> with other Java API's, such as Servlets, EJB, etc. Let's keep it that
> way.
>
I agree. Model 2 is useful when you are trying to create an a new kind of
solution _around_ JSP, and not just use JSP. For example, imagine that I
want to have a system that uses eXtended Style Sheets with XML embedded
into JSP, and that the JSP files are stored in a distributed directory
service. This is a perfect example of where to use Model 2: you would
first use a servlet to retrieve the selected JSP file out of the directory
service, process the XSL on the XML in the JSP file, and only _then_ call
the JSP file. So model 2 is good for systems-building kinda stuff.
> Regards
>
> Drew Cox
> Barrack Consulting
>
> ------Original Message
> "Vanlerberghe, Luc" wrote:
> >
> > I understand that a no-arg constructor is needed to allow the JSP
> engine to
> > construct an instance if it's not yet present, but why is it mandatory
>
> It is mandatory for 2 reasons:
>
> 1) if the named instance is not available at "request time" then
> the
> tag implementation must either; create it, or signal an
> error.
> Such late notifications of errors is not a good programming
> model,
> so we prefer "creation" semantics.
>
> 2) assuming creation semantics, it is far more efficient to
> generate
> the creation code at "translation" time, rather than using
> introspection
> at runtime.
>
> Note also the tag is called "usebean" not "useobject", a
> JavaBean is
> required to have a public no-args constructor. If you want other
> semantics you should be arguing for a "useobject" tag.
>
> We could consider splitting the tag into two:
>
> <jsp:createbean ...>
>
> <jsp:defineobject ...>
>
> that may solve part of your problem ... but I am not sure it's
> motivated
> at this stage.
>
> > (spec. footnote on page 56) if you make sure that an instance will be
> > available for the page to use? You can do this either by using the
> 'model
> > 2' approach of jsp 0.92 (ie. a servlet creates the objects) or using
> the
>
> We dont actually believe that "model 2" is the preferred model
> for JSP usage, JSP's *do not* typically require Servlet
> "masters"
> in order to create applications. Servlets (in our view) are an
> abstraction of last resort, when JSPs alone cannot be used to
> solve a problem.
>
> > redirect or include application models of the jsp 1.0 spec.
>
> This would still work using the defined "usebean" semantics.
> >
> > In fact, why not allow an interface to be used in the 'class'
> attribute of
> > the usebean tag?
>
> Because an interface is not a Bean! ... part of the problem here
> is
> that usebean is overloaded. It has create semantics along with
> use
> semantics.
>
> The feature you are asking for is incomplete, you want a
> mechanism
> that defines "at the tag level" a new name/type in the scripting
> language, and a mechanism to obtain a "pre-existing" object
> reference
> for that name. This is incomplete, one should also be able to
> construct such an object also "at the tag level", simple
> instantiatation
> is insufficient, you want late binding ... so we would need some
> sort
> of factory mechanism to provide implementations ...
>
> This is something we may consider for JSP 1.1.
>
> >
> > This would decouple the data generation/presentation even more since
> you
> > could build more generic JSPs. As it is now, a JSP is locked to the
> > inheritance tree of a certain bean class, while it might otherwise be
> made
> > generic enough to be used for all sorts of beans (especially if you
> want to
> > start building a library of JSPs that can be included in other pages)
>
> Understood.
>
> >
> > An simple example would be a JSP that's specialised in displaying
> lists of
> > names (perhaps using pretty colours or formatted as an option list in
> a
> > form). It only requires that your bean has the multivalued property
> "name",
> > so it can get the lines by calling String getName(int index).
> > Instead of requiring that all beans that use this page derive from a
> common
> > base class (and requiring changes everywhere if the hierarchy changes
> for
> > whatever reason), you could specify that the bean must implement a
> certain
> > *interface*. It doesn't concern the JSP builder what other properties
> the
> > bean has, only that it has the ones declared in the interface.
> >
> > This would also reduce the need to create 'wrapper' beans for your
> data (in
> > the worst case the programmer can then even pass his complete servlet
> to do
> > some quick and dirty testing of the JSP page). You can have a bean
> > representing your data implementing multiple interfaces to suit the
> JSPs it
> > will be used in.
> >
> > In fact, some of the implicit objects in a JSP are declared through
> > interfaces (like javax.servlet.http.HttpServletRequest (btw. that's a
> type
> > in the spec, they left out the .http bit))
> >
> > I haven't tried it yet, but I would be surprised if some of the
> reference
> > implementations don't already allow this. It probably just depends on
> what
> > tests they do while introspecting and if they generate a "new
> classname();"
> > instruction for the 'not-found' case or the more generic (and at least
> > compilable if classname is an interface)
> > "Class.forName("classname").newInstance();".
>
> This is not efficient, and also results in a runtime error ...
> not a
> good programming model, even when specified!
>
> - Larry Cable.
> >
> > Luc
> >
> > > -----Original Message-----
> > > From: LAURENCE CABLE [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, May 07, 1999 10:51 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: usebean
> > >
> > >
> > > "Kirkdorffer, Daniel" wrote:
> > > >
> > > > Which is why Integer objects for instance can't be JSP
> > > beans - they lack a
> > > > no-arg constructor.
> > > >
> > >
> > > Well, firstly, they are not Beans ... they are
> > > objects, there is a
> > > difference!
> > > Secondly, I dont really think that an Integer is a
> > > valuable abstraction
> > > as a
> > > bean anyway. Then finally, if it is of value, it
> > > would'nt be hard to
> > > work around
> > > this ...
> > >
> > > 8^)
> > >
> > > > Dan
> > > > --
> > > > Daniel Kirkdorffer
> > > > NACN IS: 425-580-6225
> > > > Sr. Consultant, Syllogistics LLC
> > > > Email: [EMAIL PROTECTED]
> > > > Web: http://www.syllogistics.com/
> > > >
> > > > > ----------
> > > > > From: LAURENCE CABLE[SMTP:[EMAIL PROTECTED]]
> > > > > Reply To: LAURENCE CABLE
> > > > > Sent: Friday, May 07, 1999 11:57 AM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Re: usebean
> > > > >
> > > > > <<File: Larry.Cable.vcf>>
> > > > > > Hi,
> > > > > >
> > > > > > I am new to JSP and have been trying to go through the
> > > JSP Version 1
> > > > > Public
> > > > > > Draft to get an idea of the concept behind JSP. While having
> > > > > declaratives,
> > > > > > actions, expressions etc. were all making sense, the
> > > one thing which I
> > > > > could
> > > > > > not be sure about was this - "When you define a class
> > > in USEBEAN, is it
> > > > > just
> > > > > > any java class or is it some kind of a special class
> > > implementing a
> > > > > certain
> > > > > > interface etc."
> > > > > >
> > > > > > I did not see anything in the documentation that talked
> > > about how to
> > > > > write
> > > > > > the beans referred to in the "USEBEAN" tag.
> > > > > >
> > > > >
> > > > > The "beans" used by the usebean tag do not need
> > > to implement any
> > > > > particular JSP dependent interface or derive from
> > > a particular
> > > > > class. The only constraint is that they implement a
> public
> > > > > "no-args"
> > > > > constructor:
> > > > >
> > > > > public class CanonicalButUselessBean { public
> > > > > CanonicalButUselessBean()
> > > > > { } }
> > > > >
> > > > > Rgds
> > > > >
> > > > > - Larry Cable
> > > > >
> > >
>
> ===========================================================================
> 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".
