Hi Daniel,
You didn't really talk about XMLC in your
discussion below.
It does seem to address many of your points.
High productivity
The clean seperation of designers and developers
during development allows fully parallelized development.
High performance
There are some large, high volume sites running on
Enhydra. The upcoming 3.0 beta will also include
EnhydraDirector, which is a high performance load
balancing connection method for web servers.
Easy modification and maintenance
Designers can modify HTML files with any HTML
editor without concern of breaking embedded Java
or templating language. Designers can verify that
the modified HTML still meets the contract expected
by the developer. Developers can modify data, business,
and presentation logic in a pure Java environment using
their preferred development tools.
Easy to understand for designers and developers
Designers don't have to learn templating syntax or worry
about programming. They just create HTML using the
tools they already know. Developers use Java and object
oriented methods to manipulate the dynamic content.
Standardized
XMLC uses HTML, XML, Java, and the W3C's DOM.
No new proprietary templating syntax to learn.
I think this meets your listed points below pretty well.
Shawn
Daniel HERLEMONT wrote:
> 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
--
Shawn McMurdo mailto:[EMAIL PROTECTED]
Lutris Technologies http://www.lutris.com
Enhydra.Org http://www.enhydra.org
___________________________________________________________________________
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
