Ok, these are just my thoughts that I sent to Jason Hunter yesterday. I have
modified them a tiny bit to reflect some of the discussion he and I had on
things in order to clarify them for you all. Please do not discuss this on
the Turbine list. :-) This is way offtopic. You can discuss these thoughts
with me privately if you want.
Also, don't get offended if you like XMLC and don't flame/hate me for this
email. I have the right to have a different opinion from you <smile>, just
like you do with me. My choice is obviously WebMacro style systems and I
don't get offended if you do not like its syntax and do not want to use it.
Although, I would like to hear your thoughts on why you do not like WebMacro
vs. XMLC. So far, I have not heard very many compelling complaints about its
way of doing things.
--------------------------------------------------------------------------
Things I like about XMLC:
It is a great idea for doing static websites. You can simply build up a
template and then replace the content as needed in the template and output
the HTML. This is similar to how James Davidson did his little application
for generating the Jakarta website. I think it works great for that type of
an application.
It also works with HTML and XML equally well. I would suggest doing the
above type implementation with Cocoon instead because that is more of the
future, but a lot of people don't want to go the XML route quite yet so
having something that deals equally well with XML and HTML is a great
benefit over Cocoon which primarily focus's on XML transformations.
Regardless, I still wouldn't use either Cocoon or XMLC for highly dynamic
sites like web applications.
Things I don't like about XMLC:
My primary interest is web applications as well as making things as easy for
the designer and engineers as possible. Designers should be able to have
full control over how things are rendered. Almost no HTML should be output
from within the application itself except under a few special cases such as
dealing with <select> elements in forms. The reason is that this allows the
designers to be able to edit as much as possible in text files without
having to re-compile java code or bug the engineers. It makes for a longer
lasting product that is easier to maintain.
So, my problem with XMLC is that for a dynamic website, it does not
encourage doing that at all. It encourages replacement of tags. Thus, when
you want to output something, you need to think about replacing a chunk of
text with another chunk of text. If that text needs to have HTML embedded
within it, then where is that HTML going to come from?
For example, the input would be:
<span id="replace">Some bold text</span>
and the output would be:
Some <b>bold</b> text
Even if you did this:
Some <span id="replace">bold</span> text
Then, if you want the word "bold" to have <b> tags around it, then you have
to do that within your Java code. That removes the power from the designer.
Having to id= everything that you want to replace is a major PITA and does
not seem like it is necessary. I think that it is a lot more empowering to
teach a page designer WebMacro's simple tags than it is to make them add id=
to elements that they want replaced. Again, this might be a good feature for
static websites, but dynamic websites are a whole different ball game.
Another thing I don't like about it is having to deal with converting the
classes into Java code and then compiling the resulting mess. If you are
making a lot of changes to a document and dealing with CVS, then checking in
the converted code is a mess. Making someone who downloads your application
also go through those contortions of compiling the code (even if it is an
Ant task) is also pretty uncool. Having simple text files that people can
modify at will and not have to run an Ant task to compile it is a lot easier
and a lot cleaner. Even if this is transparent to the end user by the app
server (like JSP is), it still is a pain because it has all of the problems
inherent with JSP such as classloader issues and disk space issues because
the system has to now manage all of that. It is overly complicated.
If your Java code depends on something that a page designer has removed, now
your Java code doesn't work. This is opposite of WM. If the designer removes
a $variable, it doesn't hurt anything. In other words, there should be no
dependency on your Java code and your HTML code. They should be able to work
separately.
There is probably more, but I really can't even come up with a single page
of things that I don't like about WM so harping on XMLC anymore really isn't
worth it. :-)
-jon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
