Hello.


I am looking for the perfect environment (I doubt it exists). Let first look
at the objective, we want all of us:
- high productivity
- high performance
- easy to modify and maintain
- easy to understand, configure and develop both for programmers and
designers
- "standardized"

I am looking closely to existing technologies: JSP, WebMacro, Freemarker,
XMLC ...
My main concern about all those templates based technologies are the
following:
- we have to learn an other language (I think there are enough existing and
powerfull technologies)
- we loose the power of JAVA:
    - object orientation, for example, can we have inheritence between
WebMacro templates
    - safety, maintenance, for example, I would like to find out most of
errors at compile time
- lack of interoperability between client and server side technologies

But I still think that all of them carry good ideas:
- JSP : close to JAVA, but we have no control on it from servlet, and it is
interpreted (tags seem to be complex even for doing simple things)
- WebMacro : I like the MVC model, where the model is your backend/business
objects, the view is the template, and the Controler the servlet. It provide
a clear separation between HTML and JAVA based stuff, between designers and
programmers. But I don't like the PERL-like syntax (too lazy - where we
loose the benefit of the strong object orientation - then why not use PHP or
PERL for all things)
- ECS : is a good and minimal starting point, but no model with it, only
wraping HTML tags in java calls, However we can extend and add high level
objects - this was the natural way when I first develop my first servlets
- Turbine seems very good and is my prefered way of acheiving all
requirements: MVC model, full JAVA, but the model seems too complex, too
many constrainsts, difficult to learn, seems to impose some type of web
servers, ....

In fact, my natural way of developing reusable servlets was to develop a MVC
model, where the servlet process incoming request and pass object to an ECS
like data type, let say: MyPage. I can then refine MyPage class to develop
the specific page of my application: query form, result pages, ....

But comming back to templates,  and what about of Javascript Server Side ?
with some powerfull JS interpreter like FESI
http://home.worldcom.ch/jmlugrin/fesi/index.html , but there and what about
http://www.plenix.org/en/software/esp/ or rather
http://www.plenix.org/polyjsp/
and why not JAVASCRIPT  based templates "Webmacro like"


In my opinion, this could be a good way to fullfil most of the objectives:
Javascript should be known from designers, see argument form the older
Netscape Javascript Server Side (but SSJS is very limited in Netscape). I
like Javascript because we can share libraries between client and server,
focusing on one technology, ...

Javascript is not so bad: very close to JAVA, some object orientation
mechanism (under used), regular expressions, ... and we can have fun with it
... and FESI is really a very good package 100% ECMA compliant, with the
capabilty to define any custom extension.
One of the most interesting feature is the liveconnect technology:  It
consist of accessing java objects form/to javascript. We can access Java
object, and fields in their native syntax, call public methods from
javascript, using  the java syntax, access to all java classes without
restrictions. On the other side, you can even call javascript from java (and
I use this extensivelly in my developments)
Liveconnect is understood by client side browser (full support in NS, and IE
provide main liveconect functions). Extensive documentation already exist
(see netscape site) Liveconnect technology  is already "well know".
Basically, this technology could provide the same feature as WebMacro, that
is accessing java object from a template, the differences is that we don't
invent a new langage and stay in the java world.

FESI support the liveconnect technology, as well as a DOM model even at
server side
then I could write server side javascript/html page and port them "as is" to
the client side, and vice versa.

I cannot summarize all the benefits: not dispersing among mutliple and new
technologies, allow high and seamless interoperability between client and
server side
The "same" page could be used at client side for applets or at server side
to generate the image from graphics objects. On the fly HTML could be
generated both at client or server side with minor modification. Server
applets could be used at server side for generating gif image from java
graphics, the same server/client code could be used to verify forms, to
genreated HTML, ...

For example, with FESI you can generate server side HTML, using  Javascript
calling ECS methods, ... building a webmacro "like" templates should be
possible but with javascript syntax ? those are simple examples comming to
my mind while writing this ... the possibilies seem to be endless


 .... client side intelligence is difficult to achieve ;-), due to the lack
of standards, and the different versions of browser, applets are difficult
to develop, interaction between applets, javascript and DHTML is a
nigthmare, but it's worth to try ... The benefits are: much better response
time since most operations are performed at client side only, minimize
server side workload, ....
and we can achieve rather complex things - see for example
http://www.com.yats/finance  (this is my site, sorry it is still in French)
once loaded at the client side, all actions are performed locally whitout
any request to the server (in fact the server could be any server serving
static files) the "database" is loaded at the client memory (in compressed
format, then you can load hundreds of entries wihtout problem), and I use
liveconnect technology extensivelly . I would like to acheive the same thing
at server side, with minimal porting effort. (client side have serious
limitation in terms of stability, memory, ...)

In conclusion, it seems to me that JAVASCRIPT server side with JAVA servlet
have already very powerfull features, and I don't see the need to reinvent
other languages or framework, I don't understand why this technology is not
so well supported.
I posted this article because it seems that nobody spoke about this (maybe
I'm wrong)

In any case, I would be very interested in having a Model View Controler
with javascript (that is invoke the template from the servlet) and something
that try to maximize common things between client/server sides. I don't know
if this already exist (I would be interested in discussions on this). I
already used FESI (in fact we can achieve most of the things with FESI only)
and I am just starting investigate other things like PolyJSP, and other,
they seem to be very powerfull,

Has anybody experience of those package ?

I don't know if they support the MVC model with full control form any
servlet.


Thank for your patience
any feedback will be appreciated.

Daniel HERLEMONT
YATS Consulting
www.yats.com
mailto:[EMAIL PROTECTED]

YATS Consulting is a small French company and very young (<6month),
specialized in Internet and Finance, working with internet brookerage
companies





-----Message d'origine-----
De : Jason Hunter <[EMAIL PROTECTED]>
� : [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date : vendredi 11 f�vrier 2000 10:21
Objet : New Servlets.com article: Reactions to "The Problems with JSP"


>Hi everyone,
>
>I just posted a new article on Servlets.com titled, "Reactions to The
>Problems with JSP". It's a collection of the most interesting feedback
>received from the article posted two weeks ago, and a look at what I
>believe the article accomplished.
>
>>From the first paragraph:
>
>  Reader reaction to the article posted here two weeks ago titled,
>  "The Problems with JSP" has been tremendous, generating around 100
>  messages on the public mailing lists (jsp-interest, servlet-interest,
>  and the official webmacro list) and nearly another 100 more to me
>  individually. This follow-on article showcases some of the most
>  interesting points made during the discussion, for those who didn't
>  get to read all the replies and to make public what people sent to
>  the feedback alias. The results were a little surprising.
>
>You can read the article at:
>
>  http://www.servlets.com/soapbox/problems-jsp-reaction.html
>
>Please think twice before posting "feedback to the feedback" on this
>list.  This thread is already getting tired.  Issues can be sent to the
>feedback alias at the bottom of the article.  (Maybe I should get a
>slashdot-style bulletin board working, but in the long term my articles
>will be more technical and less controversial, so...)
>
>-jh-
>
>___________________________________________________________________________
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff SERVLET-INTEREST".
>
>Archives: http://archives.java.sun.com/archives/servlet-interest.html
>Resources: http://java.sun.com/products/servlet/external-resources.html
>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to