Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Application Server that Allows Separated Content? 24

Posted by Cliff from the removing-nasty-HTML-from-your-code dept.
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?"
This discussion has been archived. No new comments can be posted.

Application Server that Allows Separated Content? More

Application Server that Allows Separated Content?

Comments Filter:

  • Zope (Score:1)

    by Anonymous Coward
    www.zope.org

    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.
  • 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).
  • Adobe GoLive (used to be GoLive CyberStudio) supports WO tags and objects from the get go. I think that Macromedia Dreamweaver does, as well. Both are very nice WYSIWYG HTML editors. I THINK that they are both cross (Mac/Windows) platform.

    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.
  • you know what?
    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.
    --

  • could you please state your reasons for disliking xsl?
    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.
    --

  • 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.
  • We're using WebObjects - because developers can code the HTML in a text editor or a WYSIWG, or using the built in WebObjects front-end tool. The developer does the actual integration between the database and the frontend.

    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.

  • I think you've just about ruled out everything.

    Reminds me of the poster I put up at my consulting business:
    1. Pick any two:
    2. Fast
    3. Cheap
    4. Professional
  • First, there are zillions of free template fill-in packages out there. It's hard to believe you can't find one that works with your app server.

    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?

  • Actually the main issues here are:
    1. Can it serve loads of pages?
    2. Can the content/update be done by a designer
    3. When creating/updating the content can a designer work on it with minimal support from a programmer?

    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:

    1. Throwing more computing power at the problem
    2. Staying with less flashy, more simple looks
    3. 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.

  • WO is good for the reasons you mentioned, but it still isn't that easy for a HTML person to work with, and very few HTML editors will support the WO tages & .wod file.

    It sounds like what you really need is some sort of template system.

  • Have you looked at Enhydra [enhydra.org]? 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.
  • 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

  • XSL/XSS/XML/XSLT/DTD [xml.org] are all required in order to make the solution work at full strength. It's a big learning curve and many people aren't comfortable with it. It's not easy to begin with and having to do it on the fly is even worse.

    Secondly, it uses a lot of really new technology and not all the kinks have been worked out yet. There are engines like Cocoon [cocoon.org], etc that you can use, but that can make things even more difficult. I am a HUGE proponent of things like XML, Java, and LDAP. I have been preaching Java to people for 6 years and my friends are FINALLY starting to listen to me. Write it one time, run it anywhere. No more porting to new hardware!

    I am also preaching about XML et al, but at the same time you have to use the appropriate tool for the job. You don't use a tactical nuke to kill a mosquito and you don't use XML for small things because the coding is so intensive.

    I suggest you visit the W3C [w3.org] and read about what's been going on and what's coming in the world of XML. When in doubt, go to the source. In this case, the folks that write the standards.

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

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close