Re: [Tm4j-developers] The Future of TM4Web

[Florian G. H. <fg...@bk...>]

Hello everyone.

On Thursday 23 January 2003 17:02, Jack Park wrote:
| My view is, therefore, that we must strive to complete the ensemble of =
Web
| applications available in Java, and do so with topic maps as the
| underlying, centralizing glue that binds. TM4J strikes me as a powerful=
 way
| to make that happen.  What the world (according to Park) is waiting for=
 is
| a light-switch easy Webportal engine built around topic maps. No user o=
f
| that engine should ever have to touch HTML, XML, XTM, or any such
| technology unless they want to. Zope/Plone is very close (but, no cigar
| quite yet) to that level of development.

Permit me to add something along these lines. Cocoon, for example, is gre=
at=20
but it's of course far from being "light switch easy" as Jack puts it.=20
Downloading and installing Cocoon, and getting it running, is a snap, and=
=20
looking at the samples and config files you just get this "wow, this is=20
really neat" kind of feeling. But if you're trying to go beyond the sampl=
e=20
applications and the trivial "Hello World" stuff, well, it's a different=20
story. As for my part, I've been trying to set up a simple processing=20
environment for all the documentation I write using DocBook, with a tiny =
web=20
GUI  for the purpose of customizing Norm Walsh's docbook-xsl stylesheet=20
collection (setting parameters, overriding templates etc.). And much to m=
y=20
despair, I failed miserably and decided I'd better go back to tweak my AN=
T=20
build environment, which is the approach I've followed ever since.

Now, as much as I'd like a ready-made DocBook XML processing environment =
=20
pluggable into Cocoon, an XTM processing environment should be just as=20
wonderful to have. I think TM4J has already taken the right steps in the=20
right direction with the approach of defining a set of interfaces to inte=
ract=20
with any number of back-ends. What TM4web should now do, in my very humbl=
e=20
opinion, is provide the connection to the other end, the whole=20
user-interaction layer. Providing XSL stylesheets for XSLT transformation=
=20
environments is one approach, Velocity templates for servlet-based=20
applications another, and GUI tools a third (insert as many others as you=
r=20
imagination allows).

If we were to define a set of guidelines describing a TM4J frontend just =
as=20
the engine prescribes the guidelines for the various backends, I think th=
at=20
might get us where we want to go. It is, of course, a whole lot more=20
difficult to do this on the user end -- as for the backends, a formal=20
definition structure is provided by the use of Java interfaces. It's=20
comparatively easy to say, this backend is TM4J 'compatible' or not -- if=
 it=20
implements the interfaces, it is, if it doesn't it's not. On the front en=
d,=20
it's a different story. When is a set of Cocoon generators, pipelines, an=
d=20
transformers (or a bunch of Velocity templates, etc. etc.) "a TM4J fronte=
nd"?=20

I believe if we had such guidelines, that could be the glue that holds a=20
"frontend framework" (call it TM4web or else) together.=20

I'm afraid that this might sound all a little like PHB-ish, commercial=20
software development style, "project charter" gibberish. I also understan=
d=20
that this calls for providing and maintaining high-quality (albeit perhap=
s=20
not even very extensive, I stress that's "quality", not "quantity"). And =
I=20
understand that my reasoning here is certainly influenced by my own=20
non-strict-coder background. All in all, I realize that perhaps you'll ha=
te=20
it. :-)

Worse still, I don't know any formal approach to defining such a set of=20
guidelines. Anybody have experience with regard to this? Would one have t=
o=20
define it in prose (such as an authoritative "TM4J frontend designer's=20
guide"), or is there something more efficient that perhaps even code=20
generators could work with? =20

My humble own bottom line is this: if we get the TM4J frontends to march =
in=20
step the way the backends do (well, except the DOM backend, for lack of t=
ime=20
on my part, mea culpa :-( ), this would really be something that could gi=
ve=20
potential users a chance to just *try TM4J out* without having to write c=
ode=20
themselves or resort to JUnit test cases. In other words, we would move f=
rom=20
appealing to developers to appealing to users. Plus, we would contribute=20
enormously to projects like Cocoon or Axis or perhaps Xindice who seem to=
 be=20
suffering from similar symptoms of users asking "OK, I see this is great,=
 but=20
What's In It For Me?"

Or am I perhaps missing the point here completely? :-)
-- Florian