RE: MVC/XML Framework Comments please
We use XSLT quite a lot. When you say web application I assume you are interested in the presentation aspects of XSLT; reason I make the distinction is because I'd say XSLT is considerably more important on the back-end (or can be, depending on your data sources). We use XSLT for presentation. We are light (very light) on JSPs, because of other architectural decisions, so the responsibility of preparing a response is delegated to a self-contained service (couple of classes, really) that use a variety of parameters to assemble XML and then apply appropriate stylesheets. We use homegrown templating for XML assembly, and make extensive use of XSLT includes. Performance is very acceptable, compared to other latencies in the system (data, wireless roundtrips, etc etc). We do not expect XSLT to handle the entire presentation problem. We have found that it is unlikely that the same app will run on both cell-phones and web-browsers; even when the same material is being presented to a cellphone or PDA, to make best use of the varying footprints one has to tailor the content enough that in effect one might as well have different content. XSLT is useful within device-classes, not across them, in general, except for trivial output. Which is no surprise. We never considered exposing designers to XSLT. We use full-fledged rules-oriented, parametrized stylesheets as opposed to fill-in-the-blanks stylesheets, and the same programmers that develop XSLT are at other times writing framework code or data access code or business logic. I don't know a whole bunch of designers, to be honest, but I don't think they'd get very far with this stuff. :-) We experimented with custom tags for XSLT in JSPs early last year; it's a nice mechanism. As I say, our decision not to work this way has to do with our decision to go easy on the JSPs. Regards, Arved Sandstrom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer Sent: Friday, April 27, 2001 9:18 PM To: Orion-Interest Subject: RE: MVC/XML Framework Comments please Doh! Sorry, that wasn't supposed to go to the list. But to keep this topic going (because I'm still undecided about what direction to go): Is anyone here besides Tim using XSLT in their web application? How do you like it? Is it easy to get designers up and running with it? How do you interface between Java and XML (jsp? building dom nodes in java? something else?) ? Thanks, Jeff -Original Message- From: Jeff Schnitzer Sent: Friday, April 27, 2001 3:38 PM To: Orion-Interest Subject: RE: MVC/XML Framework Comments please I'm definitely interested in your framework; may I have a copy? Thanks, Jeff -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 2:39 PM To: Orion-Interest Subject: RE: MVC/XML Framework Comments please I use my own framework for a couple of sites, and have gotten feedback from others using it as well. Its only 15K in size, full source, its free to use, modify, etc. If your interested in it, send me an email. It supports xsl transformations, and is very similar to Struts only that I found struts too much for my needs, and some features it didn't do that I needed, so I went that direction. -Original Message- From: Vic Cekvenich [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 11:53 AM To: Orion-Interest Subject: MVC/XML Framework Comments please We are bout to pick a a framework, and I am looking for are comments or recommendation on a frameworks, other than Struts. (Don't want to be HTML/JSP centric) Any feedback on your experience with a framework, or do you know of web sites in production that are using a certain frame work, or do you know of friend or someone who has used one. I would like it to be XML centric, and MVC. For example, the V should apply the XSL to XML, to make it HTML. It should do standard session tracking. It should do standard data manager, so that Java Beans do the SQL (the M). A minor plus is form entry management and a bit of image/content management. It should be a single rich framework. Here are a few we are considering: http://www.jcorporate.com/html/products/productsfm.html http://www.jcorporate.com/html/products/productsfm.html http://jakarta.apache.org/jetspeed/site/index.html http://jakarta.apache.org/jetspeed/site/index.html and all the ones under Jakarta. We need to pick one soon. Any comments and feedback welcome on frameworks/class libraries. Thanks, [EMAIL PROTECTED]
Re: MVC/XML Framework Comments please
Hi Jeff, As I mentioned in a previous post, we are also using XSLT in our applications (we've implemented around 10 so far). We already tried different approaches, namely Oracle Application Server PLSQL Cartridge, JDBC servlets, JSP + JDBC Servlets, JSP + EJB, as things were evolving. The story then goes like that Instead of using JSPs directly, we developed, as many people have done, our own Model 2 - Servlet controller framework. The JSDK specification left a couple of holes (security, application events...) that we also tried to fix with our framework. After that, there are two things that were gibing us headaches when developing web apps: .- Implementing the data layer .- Creating/Modifying the interface without having a programmer handy. Implementing the data layer using EJB is, unless you have lots of bucks to invest in a good GUI tool, a PITA. You have dozens of tables and relationships, bla, bla and you end up replicating this desing with dozens of JavaBeans and lots of getters/setters that do pretty much nothing new. And then relationships are not easily handled (it seems that specification 1.0 was created to develop 1-table applications ;)) and complex queries have to be writen by hand. You end up transforming your data from SQL to Java and then formatting it with JSP. As we were positive we were going to use Oracle, we developed a utility that allows us to write the data layer directly in PLSQL. This way if you specify the XML interface correctly, you can have a programmer that knows nothing about Java or web applications implementing your data layer. In order to modify the interface, you have to choose between making it easy to designers, or making it flexible. Using JSPs you cannot 100%-isolate the HTML code and the Java code. Even using custom tags. And telling them you cannot touch that is not enough in some cases, if they want to change some weird layouts. You can almost get it if you develop a complete set of custom tags to allow you to get the data in different orders, conditional code... but then you end up having pretty much with XSLT already has. It is not that with JSP you cannot do it but we prefer to have the designer on his own. That is what he can do with an HTML prototype and the XML specification: he can work on his own with a test XML file and he won't break any code, because there's not a single line of logic written by a developer in there. This is not a perfect solution, as XML/XSLT tools are nowadays quite young but we hope that tools will improve on that regard. We find it better to train a designer to use XSLT, which is a standar, than a set of custom tags that are not really useful outside the JSP scope. But as I said, it is not a one size fits all solution, but it is quite flexible. If we wanted to use EJBs with another database, we would then probably use JSPs to format the XML (still done by the developer) and the designer won't even know that we have changed the backed, as long as the XML is the same. Of course, just a personal opinion ;). D. Jeff Schnitzer wrote: Doh! Sorry, that wasn't supposed to go to the list. But to keep this topic going (because I'm still undecided about what direction to go): Is anyone here besides Tim using XSLT in their web application? How do you like it? Is it easy to get designers up and running with it? How do you interface between Java and XML (jsp? building dom nodes in java? something else?) ? Thanks, Jeff -Original Message- From: Jeff Schnitzer Sent: Friday, April 27, 2001 3:38 PM To: Orion-Interest Subject: RE: MVC/XML Framework Comments please I'm definitely interested in your framework; may I have a copy? Thanks, Jeff -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 2:39 PM To: Orion-Interest Subject: RE: MVC/XML Framework Comments please I use my own framework for a couple of sites, and have gotten feedback from others using it as well. Its only 15K in size, full source, its free to use, modify, etc. If your interested in it, send me an email. It supports xsl transformations, and is very similar to Struts only that I found struts too much for my needs, and some features it didn't do that I needed, so I went that direction. -Original Message- From: Vic Cekvenich [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 11:53 AM To: Orion-Interest Subject: MVC/XML Framework Comments please We are bout to pick a a framework, and I am looking for are comments or recommendation on a frameworks, other than Struts. (Don't want to be HTML/JSP centric) Any feedback on your experience with a framework, or do you know of web sites in production that are using a certain frame work, or do you know of friend or someone who has used one. I would like it to be XML centric, and MVC. For example, the V should apply the XSL to XML, to make it HTML
RE: MVC/XML Framework Comments please
We're struggling with struts in WebLogic (yuck) right now. Could we please get a copy of your framework? Very much appreciated... -Rich --- Duffey, Kevin [EMAIL PROTECTED] wrote: I use my own framework for a couple of sites, and have gotten feedback from others using it as well. Its only 15K in size, full source, its free to use, modify, etc. If your interested in it, send me an email. It supports xsl transformations, and is very similar to Struts only that I found struts too much for my needs, and some features it didn't do that I needed, so I went that direction. -Original Message- From: Vic Cekvenich [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 11:53 AM To: Orion-Interest Subject: MVC/XML Framework Comments please We are bout to pick a a framework, and I am looking for are comments or recommendation on a frameworks, other than Struts. (Don't want to be HTML/JSP centric) Any feedback on your experience with a framework, or do you know of web sites in production that are using a certain frame work, or do you know of friend or someone who has used one. I would like it to be XML centric, and MVC. For example, the V should apply the XSL to XML, to make it HTML. It should do standard session tracking. It should do standard data manager, so that Java Beans do the SQL (the M). A minor plus is form entry management and a bit of image/content management. It should be a single rich framework. Here are a few we are considering: http://www.jcorporate.com/html/products/productsfm.html http://www.jcorporate.com/html/products/productsfm.html http://jakarta.apache.org/jetspeed/site/index.html http://jakarta.apache.org/jetspeed/site/index.html and all the ones under Jakarta. We need to pick one soon. Any comments and feedback welcome on frameworks/class libraries. Thanks, [EMAIL PROTECTED] = -Rich Richard E. Sansom [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
RE: MVC/XML Framework Comments please
Title: RE: MVC/XML Framework Comments please Thanks everyone. I will first say that I have asked a similar question in 2 newsgroups and another mail list. The Orion Mail list gave 10 times more input and 10 times higher quality than any other mail list. Here is what I plan to recommend. We will use Data Access Object in the back (so we can change that to be an Astral Clones Pattern later). This ADO layer cache transparently. I am leaning towards Jet Speed in the middle, because it has Portal capabilities. (A 2nd part of our application that need to be high speed will be hand crafted). In the presentation, I plan to do similar to bellow, or XSLT with pre compiled cached sheets. It is interesting to not that there is an upcoming Java One session that talks about using JSPs for XSLT somehow, and I will go to it to see what that is about. Again, thanks for great input to the a dozen who responded. Vic -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 4:11 PM To: Orion-Interest Subject: RE: MVC/XML Framework Comments please Your message is very timely, because I'm currently doing the same sort of research. I wrote my site ( www.similarity.com http://www.similarity.com , an amusing basement project) using Rickard Oberg's WebWork MVC framework to produce HTML directly, but now my team and I are exploring more sophisticated options. My desire is for an MVC framework which generates XML. The XML would then be transformed with XSLT on the way out by a filter. Orion already does this transformation if your output is XML; take a look at $ORION_HOME/default-web-app/examples/xsl. So it really doesn't matter what MVC/templating framework you use as long as you generate XML; Struts would work fine. In fact, yesterday we wrote a spike solution using Struts (which now works out-of-the-box with Orion 1.4.8) to generate XML and transform it using the stylesheet tag in the XML document. It works great. I've been spending a lot of time researching MVC frameworks, and I'm happy to offer my thoughts so far: In the pure form, there are three stages we wish to isolate in building our html (or wml, or whatever) pages: Logic (the algorithmic world of code), Content (the meaninful information which may be static or may have been generated by logic), and Presentation (content transformed into html, wml, pdf, or whatever can be attractively rendered for display). MVC frameworks like Struts and WebWork do not distinguish between Content and Presentation. Really the MVC Framework just covers the first two phases of a Web Publishing Framework. The third phase is covered by XSLT transforming filters applied to the View after generation. Orion provides this automatically. Within the MVC process, however, there is another templating/transformation process to build the Content from the Logic. Some frameworks (Struts and WebWork) use JSP optionally with custom tag libraries. Some frameworks (Turbine) allow you to plug in a variety of templating systems, such as Velocity. Cocoon uses XSP (Xml Server Pages). This is entirely independent from the Content to Presentation transformation process which occurs later using XSLT. It sounds like Tim has a homebrew system for going directly from Logic to Presentation. My team has been thinking of eventually writing a wrapper to expose JavaBeans (the model) as a DOM using reflection so you could still have a pull-based system rather than having to build the full tree ahead of time. I'm not sure it's ultimately desirable to skip the Logic-Content step, although it would improve performance. As far as specific frameworks go: Cocoon is the most comprehensive solution. Cocoon2 sounds like it's going to be even better. I'm not too fond of this framework though because you have to be able to stomach XSP. The syntax isn't very elegant, IMHO. I didn't look too closely at how their controller system works. Struts is pretty complicated, but it has a large support community and a lot of developers working on it. For a templating system you can use either straight JSP or their elaborate set of taglibs. It provides good delineation of M, V, and C but it feels like you're programming fairly close to the servlet api. I'm sure this is easily avoided with a few support classes. Struts seems to be the favorite framwork of the Sun blueprints authors, which gives it a lot of longevity. WebWork is very much like Struts, but simpler (good), less mature (bad), and lacking a development community (fatal). The author is a smart guy, but he's just one guy, and he doesn't seem interested in moving the project towards a community development process. One thing I *don't* like about WebWork is that it tries to abstract the MVC system away from servlets so that it could conceivably be used with Swing as well. This makes doing simple things like issuing redirects rather than
Re: MVC/XML Framework Comments please
Cory Updyke wrote: My issue with XML/XSL transformations is this: My theory for the presentation tier is to keep it as simple as possible. Occasionally, you find a designer who has every right to be a engineer, but designs because they enjoy it. This person will scoff(sp?) at the simplicity of XSL. Most of the time you will find designers who know HTML (PDF, etc.). Which concept is closer to HTML, XML/XSL or JSP? I think JSP. I also have found it easier to say Do you see the green (or whatever color depending upon your IDE) colored text? Please don't delete that than it is to teach someone the concept behind XSL. You can have a good hour conversation, hand them the JSP Syntax Reference document and say DESIGN good man. I totally agree! Some years ago (before JSP) we implemented an XML based publishing system. We used our own template language which was a simplified version of XSL. The platform was techinically excellent and contained more than 150.000 lines of Java code. We had a very complex layered caching mechanism: cache for data objects, cache for XML data sources, cache for precompiled templates, cache for generated HTML snippets etc. The bad news for us came later. The system was a way too complex for our designers and HTML coders! It took relatively long time to do simple things. In other words, we went too far with the abstraction. Anyway... enough talk... we use Struts and our own Model-2-Brew. That's what we do also nowdays. We use Struts with some own add ons which allow us to configure the caching policies and access control lists for each action in struts-config.xml. Business objects and processes are without an exception implemented as EJBs. Joni [EMAIL PROTECTED]
Re: MVC/XML Framework Comments please
I have to say that I have been reading every response in this thread and find it to be one of the more interesting discussions I've heard in a while. Choosing the right framework for a project is, in my opinion, the most critical aspect in any implementation. I think it would be nice to have a more formal presentation of some of the ideas expressed here. If anyone has any good reference material (books, sites, etc) dealing with this subject I'd be very interested to look at them. Thanks. John -Original Message- From: Joni Suominen [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Date: Saturday, April 28, 2001 7:10 AM Subject: Re: MVC/XML Framework Comments please Cory Updyke wrote: My issue with XML/XSL transformations is this: My theory for the presentation tier is to keep it as simple as possible. Occasionally, you find a designer who has every right to be a engineer, but designs because they enjoy it. This person will scoff(sp?) at the simplicity of XSL. Most of the time you will find designers who know HTML (PDF, etc.). Which concept is closer to HTML, XML/XSL or JSP? I think JSP. I also have found it easier to say Do you see the green (or whatever color depending upon your IDE) colored text? Please don't delete that than it is to teach someone the concept behind XSL. You can have a good hour conversation, hand them the JSP Syntax Reference document and say DESIGN good man. I totally agree! Some years ago (before JSP) we implemented an XML based publishing system. We used our own template language which was a simplified version of XSL. The platform was techinically excellent and contained more than 150.000 lines of Java code. We had a very complex layered caching mechanism: cache for data objects, cache for XML data sources, cache for precompiled templates, cache for generated HTML snippets etc. The bad news for us came later. The system was a way too complex for our designers and HTML coders! It took relatively long time to do simple things. In other words, we went too far with the abstraction. Anyway... enough talk... we use Struts and our own Model-2-Brew. That's what we do also nowdays. We use Struts with some own add ons which allow us to configure the caching policies and access control lists for each action in struts-config.xml. Business objects and processes are without an exception implemented as EJBs. Joni [EMAIL PROTECTED]
Re: MVC/XML Framework Comments please
Hi, As we have also rolled our own solution, I'll just add my two cents. As Tim, we found that the existing frameworks didn't fit quite well into what we wanted to do, (that was even before Struts was created) and as we wanted to integrate other features... Following the Model 2-controller servlet approach, we have a centralised servlet, driven by an XML file, that specifies XML/XSLT sources for any given path. However, most of the times we are not generating XML in Java, but directly from PLSQL. We think that EJB is too much/too painful to develop for most of our applications so we developed a small library that allows us to generate the XML content directly from PLSQL. If you need to handle session values and the like, you can also use JSPs to generate part of the XML and integrate it with PLSQL generated XML. We also provide ways to modify the defined sources (XML or XSLT) on a per-request basis so it is quite flexible. We also use precompiled style-sheets, which, last time I checked, boosted our performance sometimes by a factor of three! Last detail I added to our XSLT cache is that precompiled stylesheets are stored through Soft References, thus preventing the cache from eating all the memory and providing a controlled degradation of service (not sure if that is the english translation ;)) We included also: .- a logging system, which we hope to be able to remove as soon as 1.4 provides something similar .- a flexible security system, which much more flexible that the one the JSDK spec. provides .- internationalisation, which allows us to change the config values depending on the language value .- browserization which also allows us to change the config values depending on the browser Agent and Accept strings. .- Our own connection pools, which we are thinking about replacing with another library... All in all... a .jar file of about 294KB The key point, IMHO, is to stick to standards as much as you can, and to allow different parts to be replaced when time comes. For example, we used to have a module that made the XSLT processing independent of the XSLT processor, now that JAXP 1.1 has done so, we removed the module and substituted it with JAXP. The better the standards, the easier to mantain our library. On the how to handle such a project side, we also follow the model of providing the designers with a set of static XML files so they can start playing with them while other people implement the logic. When logic is ready, you substitute XML_SOURCE=/.../static.xml with XML_SOURCE=plsql://.../package.procName and almost voilà ;). Almost because you still have to check that parameters are passed and things like that. We are pretty happy with it, as it allows us to concentrate on the real application (presentation-XSLT, logic-PLSQL/BDD) and we don't have to spend that much time developing Beans, interfaces... If we needed to, we would be able to use EJB, but for us it's been not worthy (so far). Just my 2ec, D. PD: We have had 5-6 applications with this system running production for a almost 1 year and half. We don't have big ones, but we have lots of them ;). Tim Endres wrote: We rolled our own servlet for this. I found none of the existing frameworks to properly address what we needed. It is not a complicated thing to write. An XML config file specifies the commands that get executed for any given pathinfo. The command is tied to an XSL stylesheet, which processes the XML that the command generates. Precompiled stylesheets are effectively XSL stylesheets that have already been parsed from the XML text into the DOM Node tree that is used by the XSLT processor. These compiled stylesheets are then Serialized out, and then Serialized back in, such that our code can then skip the cost of parsing the XSL's XML file, in exchange for the cost of serialization. tim. Tim, that sounds v.interesting. Forgive my ignorance but what toolkit are you using and what do you mean by precompile the XSL pages? Thanks, Trevor On Thu, 26 Apr 2001, Tim Endres wrote: We do exactly what you propose. A servlet drives lightweight commands. The commands get XML trees containing the HttpServletRequest information, and fill in a subtree with the XML results. This tree is fed into XSLT and the resulting HTML is sent down the wire. I prefer it over JSP by miles. We precompile the XSL pages, so we get really good performance. And the separation of content/presentation could not be better. tim. SNIP
RE: MVC/XML Framework Comments please
This may be off topic a little, but I am a little disheartened to see so many people disregarding EJB when considering a internet application framework. If you disregard transactions (NotSupported), and follow a few simple patterns (see java.sun.com/j2ee) you basically are able to build a powerful resource engine, which also completely isolates your business logic from your presentation tier. Although, you may be able to argue (trust me, I have done it in the past) that a JavaBean hitting a database is the same thing as an EJB call, it is likely that you will be wrong. Unless you have a server in Denver, CO talking to a server in Australia (which very seldom happens) the amount of time saved by having your resources (instance pools, db pools, jndi references, rmi pools, whatever else you can dream up) cached in the EJB server (even with RMI overhead), will blow the time it takes to make a DB request away. If you question this, run some tests. I have attempted to beat EJB performance by using a small self contained library a million times, and have seldom succeeded. I would recommend, unless your project is exceptionally simple, that a simple EJB logic abstraction is a valid consideration for the project. Back to the conversation. All of the recommendations for the web tier I believe are good, and come from years of development headaches that I am sure everybody has experienced. In reference to the web tier, the question that comes to mind when following this thread, is what are the needs of the system that is to be built. On one hand maintence is very important, but on the other hand, every abstraction hits performance. On one hand abstraction of content using XML is one of the most flexible ways to develop an internet application framework, but on the other hand, does your login page really need to be represented as an XML entity. Furthermore, is an additional transformation layer (cached or not) really worth it in terms of maintanence, performance, etc. I guess my point is, I have never found a global approach to data/presentation abstraction which I wasn't required to violate for a specific case. In fact, I have usually found that when approaching (an attempting to select) an architecture I often think this is too complex from my needs, only later to find that I needed most of what it had to offer and just didn't know it at the time (and had to build it myself in the long run). My issue with XML/XSL transformations is this: My theory for the presentation tier is to keep it as simple as possible. Occasionally, you find a designer who has every right to be a engineer, but designs because they enjoy it. This person will scoff(sp?) at the simplicity of XSL. Most of the time you will find designers who know HTML (PDF, etc.). Which concept is closer to HTML, XML/XSL or JSP? I think JSP. I also have found it easier to say Do you see the green (or whatever color depending upon your IDE) colored text? Please don't delete that than it is to teach someone the concept behind XSL. You can have a good hour conversation, hand them the JSP Syntax Reference document and say DESIGN good man. Anyway... enough talk... we use Struts and our own Model-2-Brew. Cory
RE: MVC/XML Framework Comments please
Cheers for Cory! Ejb is THE way to do persistance. By using EJB's properly, we make use of all of Orion's resource handling capabilities...and these guy's at Orion are much better at this than I am. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Cory Updyke Sent: Friday, April 27, 2001 10:05 AM To: Orion-Interest Subject: RE: MVC/XML Framework Comments please This may be off topic a little, but I am a little disheartened to see so many people disregarding EJB when considering a internet application framework. If you disregard transactions (NotSupported), and follow a few simple patterns (see java.sun.com/j2ee) you basically are able to build a powerful resource engine, which also completely isolates your business logic from your presentation tier. Although, you may be able to argue (trust me, I have done it in the past) that a JavaBean hitting a database is the same thing as an EJB call, it is likely that you will be wrong. Unless you have a server in Denver, CO talking to a server in Australia (which very seldom happens) the amount of time saved by having your resources (instance pools, db pools, jndi references, rmi pools, whatever else you can dream up) cached in the EJB server (even with RMI overhead), will blow the time it takes to make a DB request away. If you question this, run some tests. I have attempted to beat EJB performance by using a small self contained library a million times, and have seldom succeeded. I would recommend, unless your project is exceptionally simple, that a simple EJB logic abstraction is a valid consideration for the project. Back to the conversation. All of the recommendations for the web tier I believe are good, and come from years of development headaches that I am sure everybody has experienced. In reference to the web tier, the question that comes to mind when following this thread, is what are the needs of the system that is to be built. On one hand maintence is very important, but on the other hand, every abstraction hits performance. On one hand abstraction of content using XML is one of the most flexible ways to develop an internet application framework, but on the other hand, does your login page really need to be represented as an XML entity. Furthermore, is an additional transformation layer (cached or not) really worth it in terms of maintanence, performance, etc. I guess my point is, I have never found a global approach to data/presentation abstraction which I wasn't required to violate for a specific case. In fact, I have usually found that when approaching (an attempting to select) an architecture I often think this is too complex from my needs, only later to find that I needed most of what it had to offer and just didn't know it at the time (and had to build it myself in the long run). My issue with XML/XSL transformations is this: My theory for the presentation tier is to keep it as simple as possible. Occasionally, you find a designer who has every right to be a engineer, but designs because they enjoy it. This person will scoff(sp?) at the simplicity of XSL. Most of the time you will find designers who know HTML (PDF, etc.). Which concept is closer to HTML, XML/XSL or JSP? I think JSP. I also have found it easier to say Do you see the green (or whatever color depending upon your IDE) colored text? Please don't delete that than it is to teach someone the concept behind XSL. You can have a good hour conversation, hand them the JSP Syntax Reference document and say DESIGN good man. Anyway... enough talk... we use Struts and our own Model-2-Brew. Cory
RE: MVC/XML Framework Comments please
We too tried to use a liteweight persistence layer (jrf) with a few extensions, and found that Orion CMP was just as fast at most things, and significantly faster at relationships. I originally felt we needed to switch because some of our beans used bidirectional relationships implemented as get methods wrapping a finder method. This led to a pretty hefty performance hit. When Orion supports EJB QL and n:m relationships (1.5.0?), I think that performance issue will be lessoned. Until then, we had to denormalize our db a little while still use CMP. While looking at the various MVC frameworks, we too couldn't find anything to meet our needs. Struts and webWork were significantly more difficult to learn, which conflicted with the idea of making JSP easier for web designers, IMHO. Freemarker looked good until I found you had to write an adapter for each bean you wanted to expose for their template engine. We ended up writing our own MVC framework because of the unique requirements of our ASP based project. About 50% finished, we have been very pleased with our choice of Orion and CMP. Michael Third Parts.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Friday, April 27, 2001 2:12 PM To: Orion-Interest Subject: RE: MVC/XML Framework Comments please Cheers for Cory! Ejb is THE way to do persistance. By using EJB's properly, we make use of all of Orion's resource handling capabilities...and these guy's at Orion are much better at this than I am. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Cory Updyke Sent: Friday, April 27, 2001 10:05 AM To: Orion-Interest Subject: RE: MVC/XML Framework Comments please This may be off topic a little, but I am a little disheartened to see so many people disregarding EJB when considering a internet application framework. If you disregard transactions (NotSupported), and follow a few simple patterns (see java.sun.com/j2ee) you basically are able to build a powerful resource engine, which also completely isolates your business logic from your presentation tier. Although, you may be able to argue (trust me, I have done it in the past) that a JavaBean hitting a database is the same thing as an EJB call, it is likely that you will be wrong. Unless you have a server in Denver, CO talking to a server in Australia (which very seldom happens) the amount of time saved by having your resources (instance pools, db pools, jndi references, rmi pools, whatever else you can dream up) cached in the EJB server (even with RMI overhead), will blow the time it takes to make a DB request away. If you question this, run some tests. I have attempted to beat EJB performance by using a small self contained library a million times, and have seldom succeeded. I would recommend, unless your project is exceptionally simple, that a simple EJB logic abstraction is a valid consideration for the project. Back to the conversation. All of the recommendations for the web tier I believe are good, and come from years of development headaches that I am sure everybody has experienced. In reference to the web tier, the question that comes to mind when following this thread, is what are the needs of the system that is to be built. On one hand maintence is very important, but on the other hand, every abstraction hits performance. On one hand abstraction of content using XML is one of the most flexible ways to develop an internet application framework, but on the other hand, does your login page really need to be represented as an XML entity. Furthermore, is an additional transformation layer (cached or not) really worth it in terms of maintanence, performance, etc. I guess my point is, I have never found a global approach to data/presentation abstraction which I wasn't required to violate for a specific case. In fact, I have usually found that when approaching (an attempting to select) an architecture I often think this is too complex from my needs, only later to find that I needed most of what it had to offer and just didn't know it at the time (and had to build it myself in the long run). My issue with XML/XSL transformations is this: My theory for the presentation tier is to keep it as simple as possible. Occasionally, you find a designer who has every right to be a engineer, but designs because they enjoy it. This person will scoff(sp?) at the simplicity of XSL. Most of the time you will find designers who know HTML (PDF, etc.). Which concept is closer to HTML, XML/XSL or JSP? I think JSP. I also have found it easier to say Do you see the green (or whatever color depending upon your IDE) colored text? Please don't delete that than it is to teach someone the concept behind XSL. You can have a good hour conversation, hand them the JSP Syntax Reference document and say DESIGN good man. Anyway... enough talk... we use Struts and our own Model-2-Brew. Cory
RE: MVC/XML Framework Comments please
Doh! Sorry, that wasn't supposed to go to the list. But to keep this topic going (because I'm still undecided about what direction to go): Is anyone here besides Tim using XSLT in their web application? How do you like it? Is it easy to get designers up and running with it? How do you interface between Java and XML (jsp? building dom nodes in java? something else?) ? Thanks, Jeff -Original Message- From: Jeff Schnitzer Sent: Friday, April 27, 2001 3:38 PM To: Orion-Interest Subject: RE: MVC/XML Framework Comments please I'm definitely interested in your framework; may I have a copy? Thanks, Jeff -Original Message- From: Duffey, Kevin [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 2:39 PM To: Orion-Interest Subject: RE: MVC/XML Framework Comments please I use my own framework for a couple of sites, and have gotten feedback from others using it as well. Its only 15K in size, full source, its free to use, modify, etc. If your interested in it, send me an email. It supports xsl transformations, and is very similar to Struts only that I found struts too much for my needs, and some features it didn't do that I needed, so I went that direction. -Original Message- From: Vic Cekvenich [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 11:53 AM To: Orion-Interest Subject: MVC/XML Framework Comments please We are bout to pick a a framework, and I am looking for are comments or recommendation on a frameworks, other than Struts. (Don't want to be HTML/JSP centric) Any feedback on your experience with a framework, or do you know of web sites in production that are using a certain frame work, or do you know of friend or someone who has used one. I would like it to be XML centric, and MVC. For example, the V should apply the XSL to XML, to make it HTML. It should do standard session tracking. It should do standard data manager, so that Java Beans do the SQL (the M). A minor plus is form entry management and a bit of image/content management. It should be a single rich framework. Here are a few we are considering: http://www.jcorporate.com/html/products/productsfm.html http://www.jcorporate.com/html/products/productsfm.html http://jakarta.apache.org/jetspeed/site/index.html http://jakarta.apache.org/jetspeed/site/index.html and all the ones under Jakarta. We need to pick one soon. Any comments and feedback welcome on frameworks/class libraries. Thanks, [EMAIL PROTECTED]
Re: MVC/XML Framework Comments please
Title: MVC/XML Framework Comments please I would be interested in reviewing a copy of your mvc/xml framework. Thanks - Original Message - From: Duffey, Kevin To: Orion-Interest Sent: Thursday, April 26, 2001 5:39 PM Subject: RE: MVC/XML Framework Comments please I use my own framework for a couple of sites, and have gotten feedback from others using it as well. Its only 15K in size, full source, its free to use, modify, etc. If your interested in it, send me an email. It supports xsl transformations, and is very similar to Struts only that I found struts too much for my needs, and some features it didn't do that I needed, so I went that direction. -Original Message-From: Vic Cekvenich [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 26, 2001 11:53 AMTo: Orion-InterestSubject: MVC/XML Framework Comments please We are bout to pick a a framework, and I am looking for are comments or recommendation on a frameworks, other than Struts. (Don't want to be HTML/JSP centric) Any feedback on your experience with a framework, or do you know of web sites in production that are using a certain frame work, or do you know of friend or someone who has used one. I would like it to be XML centric, and MVC. For example, the V should apply the XSL to XML, to make it HTML. It should do standard session tracking. It should do standard data manager, so that Java Beans do the SQL (the M). A minor plus is form entry management and a bit of image/content management. It should be a single rich framework. Here are a few we are considering: http://www.jcorporate.com/html/products/productsfm.html http://jakarta.apache.org/jetspeed/site/index.html and all the ones under Jakarta. We need to pick one soon. Any comments and feedback welcome on frameworks/class libraries. Thanks, [EMAIL PROTECTED]
RE: MVC/XML Framework Comments please
Is anyone here besides Tim using XSLT in their web application? I've been using XSLT for some time. I think a lot of the MVC dicussions show that people haven't yet hit on the right application model. MVC really works well in an environment with shared state... and ahred access to objects. The web makes that a bit harder than one would like. I use XSLT in 2 major modes: one as a JSP tag that can transform it's body content, and as a servlet that can transform the content of an arbitrary URL. One of the biggest design decisions is whether you are doing delivery or building an application: the architectures you'll choose are very different. You may be interested in a couple of papers I wrote a while ago: http://www.mind-to-mind.com/xml/articles/xslbeans/index.html I'm in the process (getting close to finished) with a prototype that provides real MVC using some of the ideas there.
Re: MVC/XML Framework Comments please
We do exactly what you propose. A servlet drives lightweight commands. The commands get XML trees containing the HttpServletRequest information, and fill in a subtree with the XML results. This tree is fed into XSLT and the resulting HTML is sent down the wire. I prefer it over JSP by miles. We precompile the XSL pages, so we get really good performance. And the separation of content/presentation could not be better. tim. We are bout to pick a a framework, and I am looking for are comments or recommendation on a frameworks, other than Struts. (Don't want to be HTML/JSP centric) Any feedback on your experience with a framework, or do you know of web sites in production that are using a certain frame work, or do you know of friend or someone who has used one. I would like it to be XML centric, and MVC. For example, the V should apply the XSL to XML, to make it HTML. It should do standard session tracking. It should do standard data manager, so that Java Beans do the SQL (the M). A minor plus is form entry management and a bit of image/content management. It should be a single rich framework. Here are a few we are considering: http://www.jcorporate.com/html/products/productsfm.html http://jakarta.apache.org/jetspeed/site/index.html and all the ones under Jakarta. We need to pick one soon. Any comments and feedback welcome on frameworks/class libraries. Thanks, [EMAIL PROTECTED]
RE: MVC/XML Framework Comments please
Title: MVC/XML Framework Comments please Vic, You've made so many early decisions that make any later decisions fait accompli. But here goes my comments. The most significant issue you can have is performance and portability. That is, can you easily make changes without breaking the system. As for performance, will the system scale just by adding servers? The xml/xsl/html view methodology is pretty well done by Cocoon. But you performance may suffer. For example, how can this take advantage of any caching technology, other than what's built into Cocoon? The jsp/servlet filter model provide a much richer way to use xml/xsl transformations to html...and you can easily cache pseudo-static content with various third-party caching tags in the jsp. None of the frameworks you mention take advantage of filters orjsp tags (well Struts has tags). By the way, just because it's a servlet or jsp doesn't mean you are generating views with html, we generate xml with the jsp's or servlets, and filters to generate the html. As for using jdbc directly from java beans...That's just about neanderthal technology now. We don't need no stinking sql code (just kidding), but cmp in ejb's is primetime, now. Any framework that makes use of backend "business methods" and not sql code should be much more "un-breakable" and portable the using beans and sql. Then you have the performance issues. You can use stateless session beans to abstract the client from the entity bean, and this gives "extreme" performance over using an a bean with jdbc/sql calls. You can use a bean for your model...but the bean should actually be using a stateless session bean to get the data. As for the controller, the most scalable thing I have seen is using a servelet/session bean as the controller. The servelet registers the various events by reading an xml config file, and then cranks up the session bean with the various event handlers. Each handler can control the model data as described above with business methods. Are your specific question: jcorporate...way over the top on the price, forget about these guys. You can get better results with opensymphony or doing it yourself. Jetspeed uses Cocoon as its underlying technology. So this means you presistance is a hack compared to what you can do with ejb's. But if you have a lot of relatively "fixed" content that does'nt really change much, this could be your best choice. regards, The elephantwalker -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Vic CekvenichSent: Thursday, April 26, 2001 11:53 AMTo: Orion-InterestSubject: MVC/XML Framework Comments please We are bout to pick a a framework, and I am looking for are comments or recommendation on a frameworks, other than Struts. (Don't want to be HTML/JSP centric) Any feedback on your experience with a framework, or do you know of web sites in production that are using a certain frame work, or do you know of friend or someone who has used one. I would like it to be XML centric, and MVC. For example, the V should apply the XSL to XML, to make it HTML. It should do standard session tracking. It should do standard data manager, so that Java Beans do the SQL (the M). A minor plus is form entry management and a bit of image/content management. It should be a single rich framework. Here are a few we are considering: http://www.jcorporate.com/html/products/productsfm.html http://jakarta.apache.org/jetspeed/site/index.html and all the ones under Jakarta. We need to pick one soon. Any comments and feedback welcome on frameworks/class libraries. Thanks, [EMAIL PROTECTED]
Re: MVC/XML Framework Comments please
Tim, that sounds v.interesting. Forgive my ignorance but what toolkit are you using and what do you mean by precompile the XSL pages? Thanks, Trevor On Thu, 26 Apr 2001, Tim Endres wrote: We do exactly what you propose. A servlet drives lightweight commands. The commands get XML trees containing the HttpServletRequest information, and fill in a subtree with the XML results. This tree is fed into XSLT and the resulting HTML is sent down the wire. I prefer it over JSP by miles. We precompile the XSL pages, so we get really good performance. And the separation of content/presentation could not be better. tim. SNIP
RE: MVC/XML Framework Comments please
Title: MVC/XML Framework Comments please I use my own framework for a couple of sites, and have gotten feedback from others using it as well. Its only 15K in size, full source, its free to use, modify, etc. If your interested in it, send me an email. It supports xsl transformations, and is very similar to Struts only that I found struts too much for my needs, and some features it didn't do that I needed, so I went that direction. -Original Message-From: Vic Cekvenich [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 26, 2001 11:53 AMTo: Orion-InterestSubject: MVC/XML Framework Comments please We are bout to pick a a framework, and I am looking for are comments or recommendation on a frameworks, other than Struts. (Don't want to be HTML/JSP centric) Any feedback on your experience with a framework, or do you know of web sites in production that are using a certain frame work, or do you know of friend or someone who has used one. I would like it to be XML centric, and MVC. For example, the V should apply the XSL to XML, to make it HTML. It should do standard session tracking. It should do standard data manager, so that Java Beans do the SQL (the M). A minor plus is form entry management and a bit of image/content management. It should be a single rich framework. Here are a few we are considering: http://www.jcorporate.com/html/products/productsfm.html http://jakarta.apache.org/jetspeed/site/index.html and all the ones under Jakarta. We need to pick one soon. Any comments and feedback welcome on frameworks/class libraries. Thanks, [EMAIL PROTECTED]
RE: MVC/XML Framework Comments please
Your message is very timely, because I'm currently doing the same sort of research. I wrote my site ( www.similarity.com http://www.similarity.com , an amusing basement project) using Rickard Oberg's WebWork MVC framework to produce HTML directly, but now my team and I are exploring more sophisticated options. My desire is for an MVC framework which generates XML. The XML would then be transformed with XSLT on the way out by a filter. Orion already does this transformation if your output is XML; take a look at $ORION_HOME/default-web-app/examples/xsl. So it really doesn't matter what MVC/templating framework you use as long as you generate XML; Struts would work fine. In fact, yesterday we wrote a spike solution using Struts (which now works out-of-the-box with Orion 1.4.8) to generate XML and transform it using the stylesheet tag in the XML document. It works great. I've been spending a lot of time researching MVC frameworks, and I'm happy to offer my thoughts so far: In the pure form, there are three stages we wish to isolate in building our html (or wml, or whatever) pages: Logic (the algorithmic world of code), Content (the meaninful information which may be static or may have been generated by logic), and Presentation (content transformed into html, wml, pdf, or whatever can be attractively rendered for display). MVC frameworks like Struts and WebWork do not distinguish between Content and Presentation. Really the MVC Framework just covers the first two phases of a Web Publishing Framework. The third phase is covered by XSLT transforming filters applied to the View after generation. Orion provides this automatically. Within the MVC process, however, there is another templating/transformation process to build the Content from the Logic. Some frameworks (Struts and WebWork) use JSP optionally with custom tag libraries. Some frameworks (Turbine) allow you to plug in a variety of templating systems, such as Velocity. Cocoon uses XSP (Xml Server Pages). This is entirely independent from the Content to Presentation transformation process which occurs later using XSLT. It sounds like Tim has a homebrew system for going directly from Logic to Presentation. My team has been thinking of eventually writing a wrapper to expose JavaBeans (the model) as a DOM using reflection so you could still have a pull-based system rather than having to build the full tree ahead of time. I'm not sure it's ultimately desirable to skip the Logic-Content step, although it would improve performance. As far as specific frameworks go: Cocoon is the most comprehensive solution. Cocoon2 sounds like it's going to be even better. I'm not too fond of this framework though because you have to be able to stomach XSP. The syntax isn't very elegant, IMHO. I didn't look too closely at how their controller system works. Struts is pretty complicated, but it has a large support community and a lot of developers working on it. For a templating system you can use either straight JSP or their elaborate set of taglibs. It provides good delineation of M, V, and C but it feels like you're programming fairly close to the servlet api. I'm sure this is easily avoided with a few support classes. Struts seems to be the favorite framwork of the Sun blueprints authors, which gives it a lot of longevity. WebWork is very much like Struts, but simpler (good), less mature (bad), and lacking a development community (fatal). The author is a smart guy, but he's just one guy, and he doesn't seem interested in moving the project towards a community development process. One thing I *don't* like about WebWork is that it tries to abstract the MVC system away from servlets so that it could conceivably be used with Swing as well. This makes doing simple things like issuing redirects rather than forwards very painful. Also, WebWork has a novel but nonstandard way of getting beans into the views, so tasks that aren't covered by the WebWork tag library result in very ugly JSP scriptlets. Turbine I've looked at the least, other than in the context of admiring the Velocity template language (Velocity integrates well with Turbine). I'd like to hear from anyone who has experience with Turbine and can comment on its upsides and downsides. I really like the elegance of Velocity, but I suspect that I'm going to stick with JSP because that's what I've been using so far. And despite being a poor standard, JSP is still a standard :-) One option that should not be overlooked is writing your own simplified MVC framework. The controllers would be JSP pages which simply create Action beans and do jsp:setProperty to populate them. The controller JSP would then forward to each view (or issue a redirect to another controller JSP). The only pain is when you have code you want to share among the controller JSPs; the solution is to push as much of the logic as possible into the Action bean. I'm seriously considering this approach
RE: MVC/XML Framework Comments please
It sounds like Tim has a homebrew system for going directly from Logic to Presentation. My team has been thinking of eventually writing a wrapper to expose JavaBeans (the model) as a DOM using reflection so you could still have a pull-based system rather than having to build the full tree ahead of time. I'm not sure it's ultimately desirable to skip the Logic-Content step, although it would improve performance. Not quite. We use Logic (Session Beans/Commands) -- Content (XML) -- Presentation (XSL). We simply apply the XSLT transform ourselves, as opposed to having Orion do it, so we can precompile and cache appropriately. I personally think that skipping the Content step is shortsighted. For instance, our web page designers never need a live system to connect to. We simply provide them with XML files and they write the XSL against the static XML files. When the XSL is dropped into the live system, it simply operates on live XML coming from the Logic layer. I think this abstraction is important. tim.
Re: MVC/XML Framework Comments please
We rolled our own servlet for this. I found none of the existing frameworks to properly address what we needed. It is not a complicated thing to write. An XML config file specifies the commands that get executed for any given pathinfo. The command is tied to an XSL stylesheet, which processes the XML that the command generates. Precompiled stylesheets are effectively XSL stylesheets that have already been parsed from the XML text into the DOM Node tree that is used by the XSLT processor. These compiled stylesheets are then Serialized out, and then Serialized back in, such that our code can then skip the cost of parsing the XSL's XML file, in exchange for the cost of serialization. tim. Tim, that sounds v.interesting. Forgive my ignorance but what toolkit are you using and what do you mean by precompile the XSL pages? Thanks, Trevor On Thu, 26 Apr 2001, Tim Endres wrote: We do exactly what you propose. A servlet drives lightweight commands. The commands get XML trees containing the HttpServletRequest information, and fill in a subtree with the XML results. This tree is fed into XSLT and the resulting HTML is sent down the wire. I prefer it over JSP by miles. We precompile the XSL pages, so we get really good performance. And the separation of content/presentation could not be better. tim. SNIP
RE: MVC/XML Framework Comments please
How do you integratecopy with dynamic content? Two layers of XSL transformation (one to mix in copy, one to mix in markup)? Or do you use JSP-type templating to build the Content XML before it is sent off to XSLT? Thanks, Jeff -Original Message- From: Tim Endres Sent: Thu 4/26/2001 5:30 PM To: Orion-Interest Cc: Subject: RE: MVC/XML Framework Comments please It sounds like Tim has a homebrew system for going directly from Logic to Presentation. My team has been thinking of eventually writing a wrapper to expose JavaBeans (the model) as a DOM using reflection so you could still have a pull-based system rather than having to build the full tree ahead of time. I'm not sure it's ultimately desirable to skip the Logic-Content step, although it would improve performance. Not quite. We use Logic (Session Beans/Commands) -- Content (XML) -- Presentation (XSL). We simply apply the XSLT transform ourselves, as opposed to having Orion do it, so we can precompile and cache appropriately. I personally think that skipping the Content step is shortsighted. For instance, our web page designers never need a live system to connect to. We simply provide them with XML files and they write the XSL against the static XML files. When the XSL is dropped into the live system, it simply operates on live XML coming from the Logic layer. I think this abstraction is important. tim. winmail.dat
