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.
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".
