Slashdot Mirror
Application Server that Allows Separated Content?
Aceticon asks: "I've been looking around for a Web Server/Application Server/Whatever solution in which the content and the presentation are separated enough to allow a designer (which at most knows HTML) to create and adjust the presentation side with minimal support from a programmer. On top of this, the solution should be scalable enough to work from a Windows NT (maybe/hopefully Linux) serving 10000 pages/day enviroment to a Sun HPC Server (or similarly sized beast) serving 1000000 pages/day. Things like XML/XSL seem unsuitable for the whole 'designer with no support' thing - encoding presentation using XSL sheets is a refined form of masochism.
The scripting solutions i've seen out there are either too techie-like (PHP), or non-scalable (ASP). Anything that needs recompiling is probably a bit too complex for somebody whose not expected to have programming abilites. Any ideas?"
I've started looking at Zope to use it as a backend for a book repository. It seems to allow for a significant split between presentation pages and logic.
It was designed to be used in the publishing industry and may fit your needs.
Disclaimer: I work for ATG.
Dynamo does exactly what you want -- it has JHTML pages with some extra tags which interface into servlets, so that designers never see Java code.
The cool bit is that there's only ONE tag. It's
<droplet bean="ForEach">
<param name="array" value="bean:SomeArray">
<oparam name="output">
This text is output for each element in the array and you can get properties of those elements (like the name) by typing <valueof param="element.name"></valueof>
</oparam>
</droplet>
So you have a concept of a mathematical function (the droplet), then you have input parameters and output parameters (which can also be chunks of HTML). It's possible to nest droplets, so that you can have another droplet in the output parameter which does something to an element, and each of these elements is a javabean. When you say "element.name", it calls getName() on the bean.
Very cool. Beats JSP out by a mile, even with taglibs.
It's hard to believe this didn't get much
traffic or replies... it's a good topic.
My recommendation is to not focus on the "application server" buzzword; just focus on technologies. If you are using Java, there are several packages out there that do this "templating" service. At my last company, we wrote a home-grown solution that (IMHO) worked even better than any of these, so home-grown is good too.
Look at these packages and evaluate them for yourself. I think any of them could work fairly well for your situation. Cocoon uses XML/XSL, but can be very well factored so that (in the end) the designer still only has to know some very simple expandible macros he can use on a page:
Cocoon
http://xml.apache.org/cocoon
This is from the Apache project, and is very
high quality and (they claim) fast. You'll
need to master XSL to have your programmers provide the "services" for the designers.
WebMacro
http://www.webmacro.org/
This is less XML-centric. It has several nice little operators. In my opinion, though, it's not as powerful as Cocoon can be. It may, however, be more simple to integrate for a smaller-scale project.
Resin
http://www.caucho.com/products/resin/index.xtp
Resin is a servlet engine + XSL processor. It
seems very powerful, and I may use it on a future project. It's licensing terms are a little strange (definately not Open Source), but it could be a legitimate choice.
It's a strange world -- let's keep it that way
Oh, I realize I focused purely on Java technologies. Sorry, that's my current focus. Other choices that make sense could be:
Zope
Custom module in Perl (we did this before going to Java, using XML::Parser, XML::Grove, and a custom template->HTML converter. It took about 2 weeks to write).
Basically, what you want is the following:
1) HTML-like files with "expanding macros" (so the designer puts in something like )
2) A processor that takes that file and performs substitutions on it. This means you either use a strict XML syntax (so you can use any XML parser as your base) or you write a customer HTML+macro processor. I prefer using XML, but then you may have to pre-process HTML from designers into XML (and cache that result).
It's a strange world -- let's keep it that way
GoLive integrates very nicely with other Adobe products, and Dreamweaver integrates nicely with Flash. Not to mention that Dreamweaver includes BBEdit, which is among the best text editors available for any platform.
Russell Ahrens
Take a look at JSP tag libraries. These allow a programmer to create new tags that can be used by the graphic artist/web page designer types. It hides all the business logic behind the tag. The presentation logic can then be manipulated purely with HTML (with the new tags). Many off-the-shelf web page designers allow the addition of custom tag libraries, as well, allowing the page designers to use the tool of their choice.
--Be human.
i understand sql (well, as far as mysql supports it anyways), and i still hate it because it is missing some very important things.
greetings, eMBee.
--
Gnu is Not Unix / Linux Is Not UniX
i do agree with you, but i haven't looked at it that much to be able to explain it, and i sure would like to be able to tell my boss why i think, xsl is not good.
greetings, eMBee.
--
Gnu is Not Unix / Linux Is Not UniX
Seriously. Server runs on Linux, Sparc, AIX, AS/400, HPUX, and probably a few others I know. Scaleable, redundant, and even does some strange-o stuff called Off Line services, where you can cache a web page locally, then work with the application while not online. Also plugs into Db2, SAP, Oracle, MS SQL, and allows you to run IIS as your web server if you so desire.
The whole Lotus.com site, and some of ibm.com is run off of Notes servers.
Java Server Pages (JSP) offers the cleanest separation of presentation from business logic. You have to have a little discipline to maintain the clear separation, but it's pretty trivial. Here's how it works:
:-)
Your web page designer uses whatever tools he likes the best to create and design the web pages. Whenever he wants to incorporate dynamic content (i.e. result sets from DB queries) he inserts an XML-like tag. At request time the JSP engine executes the method specified in the XML-like tag. So, your designer has to learn a few new tags, but that's no biggie for any designer that doesn't rely on WYSIWYG tools for page design.
Your web application developer writes JSPs (or Servlets) that define the methods called from the designer's XML-like tags. The app developer never needs to muck around with HTML, with the exception of providing pre-formatted HTML results from the method calls (if you want to get that fancy).
In short, each person gets to focus on using their specific skill set. They work on different files so they aren't stepping on each other's toes during the development process. They clearly define a service (or API, if you like) so that the web page developer knows the library of tags available, and the developer knows what functionality each tag needs.
Best of all, the Apache Group is responsible for the reference implementation of the JSP engine, called Jakarta/Tomcat. (Sun has farmed the work out to them.) It should run fine on your favorite Linux or BSD distro, as well as some other platforms we don't mention in polite company.
Take a look at <http://java.sun.com/products/jsp/index.html>, or <http://jakarta.apache.org/> for more details, tutorials, and downloads.
contact me. i'll send you some details of something that might fit you, but it'll cost you something like $50-60K.
(ease of use) xor (scalability) the complexity has to go somewhere, and scalability is where is goes if the product is easy to use.
WO has been around for several years, is tremendously scalable, and is quite powerful
Basically these days Apple is going the Java route, so although you can code in WO using Java or Objective-C, Java is the way to go.
There's a fair learning curve associated with learning to develop in WO, but once you learn it, you've got a serious toolkit, rather than a "targeted solution" shrinkwrap affair. It can pull from practically any data source, has built-in load-balancing features, and utilizes a very sophisticated object framework.
You can develop on NT or OS X Server, and can deploy on NT, OS X Server, HP UNIX, and the strong rumor is that the next rev will deploy on Linux - it's being rewritten completely in Java.
Read the EFF's Fair Use FAQ
Reminds me of the poster I put up at my consulting business:
You quitting proves that the karma kap worked. The most annoying of the whores shut up. --CmdrTaco
Second, it only takes about a day to write your own template fill-in routines in whatever language your app server uses. It can be dead simple--just open a template file (cache it for performance) and replace placeholders ($foo, <var>foo</var>, whatever makes you happy) with supplied values. You have the code compute all the placeholders, then call the template fill-in routine.
HTML hackers work on the templates and don't have to worry their little heads over anything more scary than your friendly placeholders. Coders just need to know what values to compute and what templates to pass them to. Not fancy, but what more do you want?
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
You need (1) to implement a high-traffic web site which serves dinamic information.
You need (2) if it's oriented to the average consumer.
You need (3) to minimize maintenance costs and speedup changes to the "looks" of the site. The situation in which a programmer has to be called to change the position of an icon in a web page is a very very bad way of maintaining a site.
There should be loads of implementations out there that have (1) and (2). I believe that the next level in quality is having (3).
I doubt it very much that an ideal solution can be found, but you can allways compensate by:
- Throwing more computing power at the problem
- Staying with less flashy, more simple looks
- Teaching the designer some basic computer principles like "for cycles"
Everything is flexible, and what's best for my needs might not be the best for others.Still, i bet there's a lot of people out there which either have used something like it, or would like to use it.
Have you looked at Enhydra? It includes XMLC which compiles static HTML files containing dummy data which can be prepared by a web designer into classes which can be used by the app programmer to display dynamic content. Take a look at it, it sounds like it might just suit your requirements. It's Java, so runs pretty much anywhere.
Cold fusion is NOT a great solution. Sure its easy to code, at least for the basic stuff, but its slow, a memory hog, and not very secure. There are a number of serious design flaws with Cold Fusion that will make any experienced programmer shudder, stupid things, like not counting from zero, and reliance on javascript and java enabled browsers for certain tags. I havn't tried any of the othere systems being mentioned here, but IMHO, Cold Fusion is NOT a Good Thing.
Where I work we tend to use websphere...i'm not a developer though. From all the groaning I hear, get something else.
You are only young once, but you can stay immature indefinitely.
This question has to do with how you generate the html (or whatever interface you choose). The app server just runs the JSP/SErvlet/code you want. I suggest looking at template engines to generate the dynamic content. These engines run in teh context of a servlet generally within the app Server. I have sucessfully built several large dynamic sites this way and it has worked quite well. Check out jakarta.apache.org and specifically within the jakarta project, look at velocity (jakarta.apache.org/velocity). Velocity is not quite ready yet, but soon. It's an open source version of what I used and appears to be ontrack to be a great product. Good Luck. Joe
Cold fusion has a more html like feel to it's dynmaic functionality, in that it is also essentially tag driven. Have you considered getting the html writer to look into learning some cold fusion tags?
I agree, if you're an experienced programmer. But he wants something with ease of use for html writers, not programmers. And I don't think there is any other simpler solution.
As for the security issues. Well I can understand the security issue, I always prefer the more secure solution even if it is more difficult to implement, but I am a programmer, not a html writer.
As for the javascript issue, I believe in this day and age people should face up to the fact that javascript in a website is a reasonable expectation, and a function that has been there for quite some time (in gui browsers). After some of the crap sites I've seen lately (flash, IE4 dhtml etc) you can't bag out something that has been there for a long time and works on most different browsers.