Re: [Tm4j-developers] The Future of TM4Web

[Martin S. <m.s...@we...>]

Hi,

a bit late, but I want to tell you some of my thoughts about this.
I think because of the restricted ressources we have (developers, time, ...)
we should concentrate on goals we are able to achieve.
Maybe there is a lack of Easy-To-Use-Webportal-Engine's in the java
open source world, but there are many efforts to develop such applications
(see cocoon, jetspeed, ...) and as you can see it costs a lot of work and
time to do this.
And I think at the time it's not really a problem, that there are no easy webportal engines
available, because most of the people who use java open source
web applications, are developers and need flexible and easy adaptable
frameworks for their projects.

Back to tm4j and tm4web: tm4j is a very powerful backend,
but what we need now are frontends to tm4j. 
tm4web is a special solution for web frontends and at the time (as I know, but
I know it not very well) it consists of a bunch of stylesheets to transform the
XML-Representation of a topic map to HTML.

tmnav is a more general approach to the frontend problem. The goal of the panckoucke library 
of tmnav is to provide a general framework to navigate and edit topic maps, undependent 
of the type of frontend. And there are some subprojects, frontends that use panckoucke,
(e.g a swing frontend, a webservice). But this means at the time it is NOT easy to use.
It is more work, because you have to provide clean interfaces and  you have to develop the
library AND frontend applications. Therefore it will not be easy to use in the near time.
But it will allow to write adapters for other web-application/web-portal-engines e.g. to
cocoon. So we do not have to reinvent the wheel again, but we can use the existing 
applications out there as frontends.
So I think with tmnav/panckoucke we have the "frontend framework" that you mentioned, but at the
time it is not in a state that allows to adapt a web-frontend easily.

So what can we do? 
One way is to develop both, the web-frontends and other frontends on base of the panckoucke-Library.
But this means a lot of communication between the developers to find out what is needed and to 
develop the interfaces. And it takes more time to develop easy-to-use applications.

Another way is to develop both, tmnav with panckoucke as general approach, and tm4web as special
web-frontend framework for tm4j. And maybe try to put them together in the far future.
But this means to do some work double.

I do not know what's the best solution. But I think we should try to find out, what are the special
demands of web applications that use tm4j and if panckoucke is/will be able to fullful this 
demands or if we need another approach. I'm very new to the tmnav-Team, so it is possible that 
it is not all correct that I said about the goals/abilities of panckoucke. I hope Niko or Christoph
will correct it or write their own opinion about it.

Bye

Martin



Florian G. Haas wrote:
> 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 of
> | 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 great 
> but it's of course far from being "light switch easy" as Jack puts it. 
> Downloading and installing Cocoon, and getting it running, is a snap, and 
> looking at the samples and config files you just get this "wow, this is 
> really neat" kind of feeling. But if you're trying to go beyond the sample 
> applications and the trivial "Hello World" stuff, well, it's a different 
> story. As for my part, I've been trying to set up a simple processing 
> environment for all the documentation I write using DocBook, with a tiny web 
> GUI  for the purpose of customizing Norm Walsh's docbook-xsl stylesheet 
> collection (setting parameters, overriding templates etc.). And much to my 
> despair, I failed miserably and decided I'd better go back to tweak my ANT 
> 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  
> pluggable into Cocoon, an XTM processing environment should be just as 
> wonderful to have. I think TM4J has already taken the right steps in the 
> right direction with the approach of defining a set of interfaces to interact 
> with any number of back-ends. What TM4web should now do, in my very humble 
> opinion, is provide the connection to the other end, the whole 
> user-interaction layer. Providing XSL stylesheets for XSLT transformation 
> environments is one approach, Velocity templates for servlet-based 
> applications another, and GUI tools a third (insert as many others as your 
> imagination allows).
> 
> If we were to define a set of guidelines describing a TM4J frontend just as 
> the engine prescribes the guidelines for the various backends, I think that 
> might get us where we want to go. It is, of course, a whole lot more 
> difficult to do this on the user end -- as for the backends, a formal 
> definition structure is provided by the use of Java interfaces. It's 
> comparatively easy to say, this backend is TM4J 'compatible' or not -- if it 
> implements the interfaces, it is, if it doesn't it's not. On the front end, 
> it's a different story. When is a set of Cocoon generators, pipelines, and 
> transformers (or a bunch of Velocity templates, etc. etc.) "a TM4J frontend"? 
> 
> I believe if we had such guidelines, that could be the glue that holds a 
> "frontend framework" (call it TM4web or else) together. 
> 
> I'm afraid that this might sound all a little like PHB-ish, commercial 
> software development style, "project charter" gibberish. I also understand 
> that this calls for providing and maintaining high-quality (albeit perhaps 
> not even very extensive, I stress that's "quality", not "quantity"). And I 
> understand that my reasoning here is certainly influenced by my own 
> non-strict-coder background. All in all, I realize that perhaps you'll hate 
> it. :-)
> 
> Worse still, I don't know any formal approach to defining such a set of 
> guidelines. Anybody have experience with regard to this? Would one have to 
> define it in prose (such as an authoritative "TM4J frontend designer's 
> guide"), or is there something more efficient that perhaps even code 
> generators could work with?  
> 
> My humble own bottom line is this: if we get the TM4J frontends to march in 
> step the way the backends do (well, except the DOM backend, for lack of time 
> on my part, mea culpa :-( ), this would really be something that could give 
> potential users a chance to just *try TM4J out* without having to write code 
> themselves or resort to JUnit test cases. In other words, we would move from 
> appealing to developers to appealing to users. Plus, we would contribute 
> enormously to projects like Cocoon or Axis or perhaps Xindice who seem to be 
> suffering from similar symptoms of users asking "OK, I see this is great, but 
> What's In It For Me?"
> 
> Or am I perhaps missing the point here completely? :-)
> -- Florian
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers