Menu
▾
▴
tm4j-developers — Forum for issues related to development of TM4J.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
(26) |
Jul
(22) |
Aug
(31) |
Sep
(25) |
Oct
(9) |
Nov
(7) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(50) |
Feb
(51) |
Mar
(6) |
Apr
(10) |
May
(4) |
Jun
(9) |
Jul
(9) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(11) |
| 2003 |
Jan
(8) |
Feb
(21) |
Mar
(2) |
Apr
(29) |
May
(9) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(3) |
Oct
(21) |
Nov
(40) |
Dec
(14) |
| 2004 |
Jan
(32) |
Feb
(30) |
Mar
(24) |
Apr
(13) |
May
(25) |
Jun
(14) |
Jul
(9) |
Aug
(21) |
Sep
(52) |
Oct
(9) |
Nov
(12) |
Dec
(6) |
| 2005 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
|
May
(6) |
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
(14) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2006 |
Jan
|
Feb
(16) |
Mar
(7) |
Apr
(7) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(9) |
Dec
(2) |
| 2007 |
Jan
(2) |
Feb
(9) |
Mar
(1) |
Apr
(38) |
May
(7) |
Jun
(7) |
Jul
(12) |
Aug
(10) |
Sep
(10) |
Oct
(3) |
Nov
(7) |
Dec
(7) |
| 2008 |
Jan
(13) |
Feb
(12) |
Mar
(53) |
Apr
(14) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Kal A. <ka...@te...> - 2003-02-26 09:55:24
|
Yes, I think that it might be beneficial to have more modularity rather than less. One minor problem with increasing modularity is going to be in maintaining a proper decoupling between the modules. I think that as long as we make it the rule that each module includes the other libraries it needs as .jar files and that the build processes only uses those libraries (i.e. no sneaky use of paths to the CVS tree of other modules ;-) then we should be safe. I see this kind of thing in the Apache projects - where for example you will find one project such as FOP settling on a build of another project such as the Commons and using that build in their project. With this safe-guard in place I would say +1 to separating tmnav and panckoucke. As for kamal, I think I would prefer to leave that to Martin's judgement - but I think that by allowing projects like kamal to choose a build from the HEAD branch of the panckoucke module, it might actually make kamal development easier as the target would not move so often. Does that make sense ? Cheers, Kal Niko Schmuck wrote: >Hi, > >While I agree completely with the separation of the tmnav and tm4web >projects, I would like to make the suggestion to have a more clear >distinction between panckoucke, tmnav and kamal. What do you think about >spending each an own CVS module (maybe calling the two new ones >'tm4access', 'tm4ws') ? This would mean basically moving panckoucke and >kamal into an own directory structure, but I think the effort pays back >in terms of easier packaging and reusability. And of course like Kal >mentioned allowing own developing speeds for example for panckoucke and >tmnav. > >Greetings, >Niko > > > > >>Kal Ahmed wrote: >> >> >>>I think I can see where you are coming from. However, I think that the >>>current division between tm4web and tmnav is about right (I'll come on >>>to the possible changes later). Currently tmnav and tm4j follow >>>different release schedules. This works because tmnav can make use of a >>>particular TM4J release and it allows the two projects to continue at >>>their own pace without one project having to wait for the other. While >>>it is (I think) possible to branch part of a CVS module, I think it is >>>generally much nicer to have separate modules for the separate >>>deliverables so that each can be labelled when it reaches a release >>>milestone. I think that it will be the case that tm4web will initially >>>develop slower than tmnav is currently developing (that is inevitable >>>because tm4web is in earlier stages at the moment) and I don't want >>>tm4web development to become a drag factor on tmnav. >>> >>>To me, there is a nice logical distinction between the client-oriented >>>presentational features of panckoucke and the tmnav application and the >>>web publishing/web application features of tm4web. I can see them as >>>being separate SourceForge downloads - tmnav for client-side developers, >>>tm4web for server-side developers. >>> >>> >>I agree with you Kal. At the current state of the two applications I think >>it makes no sense to put them together in one project. >> >> >> >> >>>The one overlap is with kamal. Perhaps kamal should move into tm4web (or >>>we should think about creating a tm4ws module perhaps) - but I guess >>>that this depends upon how tightly tied kamal is to the panckoucke >>>libraries and whether or not we could achieve a degree of independence >>>like exists between tmnav and tm4j. >>> >>> >>Kamal is/will be a webservice-representation of a subset of the >> >> >panckoucke-Interface. > > >>So it depends on panckoucke at the moment. I'm working on the internal >> >> >interfaces at the time > > >>and it will be more independent of the navigation backend. But I'm not >> >> >sure if it makes > > >>really sense to decouple the two completely. >> >>It think the only overlap of tm4web and kamal is that both are server >> >> >side applications > > >>and both use a servlet engine to provide it's services. But the goals >> >> >of both are different: > > >>tm4web provides a web-based interface for 'users', kamal provides a >> >> >webservice based > > >>programming interface for 'user-applications'. >>So what is the benefit, if we put tm4web and kamal together in one >> >> >project? > > > >------------------------------------------------------- >This SF.net email is sponsored by: Scholarships for Techies! >Can't afford IT training? All 2003 ictp students receive scholarships. >Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. >www.ictp.com/training/sourceforge.asp >_______________________________________________ >Tm4j-developers mailing list >Tm4...@li... >https://lists.sourceforge.net/lists/listinfo/tm4j-developers > > > > |
|
From: Niko S. <ni...@na...> - 2003-02-26 09:36:40
|
Hi, While I agree completely with the separation of the tmnav and tm4web projects, I would like to make the suggestion to have a more clear distinction between panckoucke, tmnav and kamal. What do you think about spending each an own CVS module (maybe calling the two new ones 'tm4access', 'tm4ws') ? This would mean basically moving panckoucke and kamal into an own directory structure, but I think the effort pays back in terms of easier packaging and reusability. And of course like Kal mentioned allowing own developing speeds for example for panckoucke and tmnav. Greetings, Niko > Kal Ahmed wrote: > > > > I think I can see where you are coming from. However, I think that the > > current division between tm4web and tmnav is about right (I'll come on > > to the possible changes later). Currently tmnav and tm4j follow > > different release schedules. This works because tmnav can make use of a > > particular TM4J release and it allows the two projects to continue at > > their own pace without one project having to wait for the other. While > > it is (I think) possible to branch part of a CVS module, I think it is > > generally much nicer to have separate modules for the separate > > deliverables so that each can be labelled when it reaches a release > > milestone. I think that it will be the case that tm4web will initially > > develop slower than tmnav is currently developing (that is inevitable > > because tm4web is in earlier stages at the moment) and I don't want > > tm4web development to become a drag factor on tmnav. > > > > To me, there is a nice logical distinction between the client-oriented > > presentational features of panckoucke and the tmnav application and the > > web publishing/web application features of tm4web. I can see them as > > being separate SourceForge downloads - tmnav for client-side developers, > > tm4web for server-side developers. > > I agree with you Kal. At the current state of the two applications I think > it makes no sense to put them together in one project. > > > > > > The one overlap is with kamal. Perhaps kamal should move into tm4web (or > > we should think about creating a tm4ws module perhaps) - but I guess > > that this depends upon how tightly tied kamal is to the panckoucke > > libraries and whether or not we could achieve a degree of independence > > like exists between tmnav and tm4j. > > Kamal is/will be a webservice-representation of a subset of the panckoucke-Interface. > So it depends on panckoucke at the moment. I'm working on the internal interfaces at the time > and it will be more independent of the navigation backend. But I'm not sure if it makes > really sense to decouple the two completely. > > It think the only overlap of tm4web and kamal is that both are server side applications > and both use a servlet engine to provide it's services. But the goals of both are different: > tm4web provides a web-based interface for 'users', kamal provides a webservice based > programming interface for 'user-applications'. > So what is the benefit, if we put tm4web and kamal together in one project? |
|
From: Martin S. <hu...@we...> - 2003-02-26 08:47:08
|
Hi, Kal Ahmed wrote: > Hi Cristoph, > > I think I can see where you are coming from. However, I think that the > current division between tm4web and tmnav is about right (I'll come on > to the possible changes later). Currently tmnav and tm4j follow > different release schedules. This works because tmnav can make use of a > particular TM4J release and it allows the two projects to continue at > their own pace without one project having to wait for the other. While > it is (I think) possible to branch part of a CVS module, I think it is > generally much nicer to have separate modules for the separate > deliverables so that each can be labelled when it reaches a release > milestone. I think that it will be the case that tm4web will initially > develop slower than tmnav is currently developing (that is inevitable > because tm4web is in earlier stages at the moment) and I don't want > tm4web development to become a drag factor on tmnav. > > To me, there is a nice logical distinction between the client-oriented > presentational features of panckoucke and the tmnav application and the > web publishing/web application features of tm4web. I can see them as > being separate SourceForge downloads - tmnav for client-side developers, > tm4web for server-side developers. I agree with you Kal. At the current state of the two applications I think it makes no sense to put them together in one project. > > The one overlap is with kamal. Perhaps kamal should move into tm4web (or > we should think about creating a tm4ws module perhaps) - but I guess > that this depends upon how tightly tied kamal is to the panckoucke > libraries and whether or not we could achieve a degree of independence > like exists between tmnav and tm4j. Kamal is/will be a webservice-representation of a subset of the panckoucke-Interface. So it depends on panckoucke at the moment. I'm working on the internal interfaces at the time and it will be more independent of the navigation backend. But I'm not sure if it makes really sense to decouple the two completely. It think the only overlap of tm4web and kamal is that both are server side applications and both use a servlet engine to provide it's services. But the goals of both are different: tm4web provides a web-based interface for 'users', kamal provides a webservice based programming interface for 'user-applications'. So what is the benefit, if we put tm4web and kamal together in one project? > Those are just my thoughts - I would be interested to hear what the > other tmnav developers think too. > > Cheers, > > Kal Greetings Martin > > On Tue, 2003-02-25 at 13:41, Christoph Fröhlich wrote: > >>Hi kal >> >>some thoughts about the tm4web - project. >> >> >>I like the idea. And I think it would be good for the tmnav-project >>to be part of the tm4web-thing. (I have not spoken with the other >>developers about this, so we should hear what they think.) But to me, >>it would be fine to be part of a subproject which works on all >>aspects of the accessibilty of topicmaps. >> >>Naturally, working on all aspects of accesibilty means more, than >>working on web-related technologies. >>Therefor I would prefer a name, which is "more open" to other >>directions, perhaps tmAccess or tmGate or something like this. >> >> >> >>Some words on TMNav >> >>TMNav consists currently of three parts. >>One is the Panckoucke-Library, which offers services for frontend-applications. >>You may use panckoucke to obtain a view on a fragment of a topicmap. >>This view reduces the complexitivity of topicmaps down to a model, >>which is easy to understand and suitable for ui-purposes . >>Furthermore the version which is currently under developement wil >>contain code to load topicmaps assynchroniously and maintan a >>repository of all loaded maps. >>We plan to add authentication and restricted access features and yes >>- i hope we will get there to support editing. >>Panckoucke is currently the heart of the tmnav-project and I think >>other projects / applications / services could benefit from it as >>well. >> >> >>Second, TMnav contains Kamal, a webservice which settles on >>panckoucke and delivers the panckoucke generated model to the world. >> >>Third TMNav contains an Application, which is unfortunately usually >>referred to as TMNav as well. Using one single name for the package >>and for one part of the package, is defintely confusing. It does not >>make it easy to understand separate things separetly. >> >>The App is swing based . In its current state it is nothing more tham >>a playground. To me, developing the Swing-App will lead into a >>dead-end-street, since we have to reinvent several wheels, in order >>to provide something which could be really suitable to work with. I >>hope tmnav will be ported to more powerful editing enviroments, as >>eclipse or jedit, where it could live on some time. >> >>This is what we are currently developing. I think at least panckoucke >>and kamal could be valuable input to the so-called tm4web-project and >>I would love to bring theese efforts together with all what is >>elsewhere under developement. And I feel, the target should be >>broader than web.... >> >> >>Regards >>c >> >> >> >> >> >> >> >> >> >> >> >> >> >>------------------------------------------------------- >>This sf.net email is sponsored by:ThinkGeek >>Welcome to geek heaven. >>http://thinkgeek.com/sf >>_______________________________________________ >>Tm4j-developers mailing list >>Tm4...@li... >>https://lists.sourceforge.net/lists/listinfo/tm4j-developers >> > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Tm4j-developers mailing list > Tm4...@li... > https://lists.sourceforge.net/lists/listinfo/tm4j-developers |
|
From: Kal A. <ka...@te...> - 2003-02-25 19:46:55
|
Hi all, In response to the growing team working on tmnav, I have created a new mailing list to act as a forum for discussion of development of the tmnav subproject. The request has gone into the SourceForge system and should be complete by this time tomorrow. The list address will be tm4...@li... (Don't try it now cos it won't work!) I look forward to seeing some of you on that list! Cheers, Kal |
|
From: Kal A. <ka...@te...> - 2003-02-25 19:41:16
|
Hi Cristoph, I think I can see where you are coming from. However, I think that the current division between tm4web and tmnav is about right (I'll come on to the possible changes later). Currently tmnav and tm4j follow different release schedules. This works because tmnav can make use of a particular TM4J release and it allows the two projects to continue at their own pace without one project having to wait for the other. While it is (I think) possible to branch part of a CVS module, I think it is generally much nicer to have separate modules for the separate deliverables so that each can be labelled when it reaches a release milestone. I think that it will be the case that tm4web will initially develop slower than tmnav is currently developing (that is inevitable because tm4web is in earlier stages at the moment) and I don't want tm4web development to become a drag factor on tmnav. To me, there is a nice logical distinction between the client-oriented presentational features of panckoucke and the tmnav application and the web publishing/web application features of tm4web. I can see them as being separate SourceForge downloads - tmnav for client-side developers, tm4web for server-side developers.=20 The one overlap is with kamal. Perhaps kamal should move into tm4web (or we should think about creating a tm4ws module perhaps) - but I guess that this depends upon how tightly tied kamal is to the panckoucke libraries and whether or not we could achieve a degree of independence like exists between tmnav and tm4j. Those are just my thoughts - I would be interested to hear what the other tmnav developers think too. Cheers, Kal On Tue, 2003-02-25 at 13:41, Christoph Fr=C3=B6hlich wrote: > Hi kal >=20 > some thoughts about the tm4web - project. >=20 >=20 > I like the idea. And I think it would be good for the tmnav-project=20 > to be part of the tm4web-thing. (I have not spoken with the other=20 > developers about this, so we should hear what they think.) But to me,=20 > it would be fine to be part of a subproject which works on all=20 > aspects of the accessibilty of topicmaps. >=20 > Naturally, working on all aspects of accesibilty means more, than=20 > working on web-related technologies. > Therefor I would prefer a name, which is "more open" to other=20 > directions, perhaps tmAccess or tmGate or something like this. >=20 >=20 >=20 > Some words on TMNav >=20 > TMNav consists currently of three parts. > One is the Panckoucke-Library, which offers services for frontend-applica= tions. > You may use panckoucke to obtain a view on a fragment of a topicmap.=20 > This view reduces the complexitivity of topicmaps down to a model,=20 > which is easy to understand and suitable for ui-purposes . > Furthermore the version which is currently under developement wil=20 > contain code to load topicmaps assynchroniously and maintan a=20 > repository of all loaded maps. > We plan to add authentication and restricted access features and yes=20 > - i hope we will get there to support editing. > Panckoucke is currently the heart of the tmnav-project and I think=20 > other projects / applications / services could benefit from it as=20 > well. >=20 >=20 > Second, TMnav contains Kamal, a webservice which settles on=20 > panckoucke and delivers the panckoucke generated model to the world. >=20 > Third TMNav contains an Application, which is unfortunately usually=20 > referred to as TMNav as well. Using one single name for the package=20 > and for one part of the package, is defintely confusing. It does not=20 > make it easy to understand separate things separetly. >=20 > The App is swing based . In its current state it is nothing more tham=20 > a playground. To me, developing the Swing-App will lead into a=20 > dead-end-street, since we have to reinvent several wheels, in order=20 > to provide something which could be really suitable to work with. I=20 > hope tmnav will be ported to more powerful editing enviroments, as=20 > eclipse or jedit, where it could live on some time. >=20 > This is what we are currently developing. I think at least panckoucke=20 > and kamal could be valuable input to the so-called tm4web-project and=20 > I would love to bring theese efforts together with all what is=20 > elsewhere under developement. And I feel, the target should be=20 > broader than web.... >=20 >=20 > Regards > c >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Tm4j-developers mailing list > Tm4...@li... > https://lists.sourceforge.net/lists/listinfo/tm4j-developers >=20 |
|
From: Jack P. <jac...@th...> - 2003-02-25 14:16:04
|
At 05:41 AM 2/25/2003, Christoph Fr=F6hlich wrote: >I hope tmnav will be ported to more powerful editing enviroments, as=20 >eclipse or jedit, where it could live on some time. I personally think that Eclipse is a great environment, except that it is=20 an enormous download, and it relies on a completely different display=20 technology than Swing or AWT, and that technology has not infected all Java= =20 platforms (yet). (Of course, you can develop in Swing if you like, but the= =20 Eclipse platform itself does not use Swing). jEdit is also powerful, but you give up the Apache license if you use any=20 part of it. While there, take a look at Jext. Sorry to sound negative here; I do like the idea of enhancing TMNav. Cheers Jack --------------------------------------------------------------------------- XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor Build smarter kids globally to reduce the need for smarter bombs. |
|
From: Christoph <cf...@fo...> - 2003-02-25 13:41:15
|
Hi kal some thoughts about the tm4web - project. I like the idea. And I think it would be good for the tmnav-project to be part of the tm4web-thing. (I have not spoken with the other developers about this, so we should hear what they think.) But to me, it would be fine to be part of a subproject which works on all aspects of the accessibilty of topicmaps. Naturally, working on all aspects of accesibilty means more, than working on web-related technologies. Therefor I would prefer a name, which is "more open" to other directions, perhaps tmAccess or tmGate or something like this. Some words on TMNav TMNav consists currently of three parts. One is the Panckoucke-Library, which offers services for frontend-applications. You may use panckoucke to obtain a view on a fragment of a topicmap. This view reduces the complexitivity of topicmaps down to a model, which is easy to understand and suitable for ui-purposes . Furthermore the version which is currently under developement wil contain code to load topicmaps assynchroniously and maintan a repository of all loaded maps. We plan to add authentication and restricted access features and yes - i hope we will get there to support editing. Panckoucke is currently the heart of the tmnav-project and I think other projects / applications / services could benefit from it as well. Second, TMnav contains Kamal, a webservice which settles on panckoucke and delivers the panckoucke generated model to the world. Third TMNav contains an Application, which is unfortunately usually referred to as TMNav as well. Using one single name for the package and for one part of the package, is defintely confusing. It does not make it easy to understand separate things separetly. The App is swing based . In its current state it is nothing more tham a playground. To me, developing the Swing-App will lead into a dead-end-street, since we have to reinvent several wheels, in order to provide something which could be really suitable to work with. I hope tmnav will be ported to more powerful editing enviroments, as eclipse or jedit, where it could live on some time. This is what we are currently developing. I think at least panckoucke and kamal could be valuable input to the so-called tm4web-project and I would love to bring theese efforts together with all what is elsewhere under developement. And I feel, the target should be broader than web.... Regards c |
|
From: Kal A. <ka...@te...> - 2003-02-07 15:01:07
|
Hi Rene, At 14:45 07/02/2003 +0100, Ren...@da... wrote: >Hi Kal, > >I just wanted to delete some topics from a topic map with 2000 Topics in it - >with the api function topic.destroy(). >In some cases I have to delete nearly all topics (I apply some filters on it) >and I woundered why I had to wait more then 10 minutes. >I took the time of a single destroy() and it was about 300 ms on a 700 Mhz >machine... Ouch! Is this with the in-memory backend or one of the persistent stores ? Without running any profiling, my guess is that this performance hit comes because the code checks that the topic you are removing is not being used as a topic/association/occurrence/role type or in a scope. Because that information needs to be looked up from the indexes, you are getting hit with the cost of the lookups. There are a number of ways this could be fixed: 1) Add a reference count to Topic objects - so a Topic can only be destroyed if its ref count is 0 2) Consolidate all topic use information into a single index - so the cost is only one lookup, not 5 (2) is probably easier to implement and will not involve changing the database schema, but (1) would be more efficient. In fact, I could probably implement (1) for the Ozone and in-memory backends and make the implementation of the getRefCount() method on the RDBMS backend use a query.... that would be almost the best of both worlds.... But before I get into making these changes, I would like to get a bit of profiling on your problem. If you have time to do that for me, that would be really helpful as I am kind of pressed for time at the moment. Cheers, Kal |
|
From: <Ren...@da...> - 2003-02-07 13:45:43
|
Hi Kal, I just wanted to delete some topics from a topic map with 2000 Topics i= n it -=20 with the api function topic.destroy(). In some cases I have to delete nearly all topics (I apply some filters = on it)=20 and I woundered why I had to wait more then 10 minutes. I took the time of a single destroy() and it was about 300 ms on a 700 = Mhz=20 machine... That is not workable because in real use cases we have to handle up to = 100 000=20 Topics. This was just a test case... Is there a chance to have this problem fixed? Greetings Ren=E9 Freude (Ren...@da...)=20 DaimlerChrysler AG=20 Research - Information & Communication=20 Software Technologies / Methods & Tools=20 (RIC/SM)=20 Berlin / Germany = |
|
From: Kal A. <ka...@te...> - 2003-02-03 19:35:52
|
Hi, Firstly, thanks to everyone who replied both on and off the list. It seems that the general consensus is that tm4web should *not* aim to be a one-size-fits-all topic map browsing/editing solution and that it should be more than the current set of (albeit very useful) stylesheets. Nailing down exactly what the in-between is that tm4web should be is going to be harder. I agree with Martin's analysis of the panckouke library - it is essentially a way to bind the topic map data model to something which is perhaps easier to process for front-ends (both web and desktop). In thinking about what everyone has written, I keep coming back to the same thoughts - that it would be really nice to have features in the TM4J library that help people trying to build web applications. There are already some classes whose motivation was web applications, such as the TopicMapManager and the TopicMapFragment classes. The whole concept of extractors and testers is also really there to help application developers (though not just for web applications). So, what could the tm4web sub-project aim to produce ? Here are my thoughts: 0) Static transformation using XSL stylesheets 1) Some utility classes for configuring the connection to one or more TM4J back-ends 2) Utility classes to support the direct interfacing of TM4J to Velocity 3) Utility classes to support the direct interfacing of TM4J to Cocoon (implemented as Cocoon transformers for example) 4) Utility classes for integrating tmnav libraries with the backend configurations from (1) and for interfacing the panckouke abstraction model to Velocity/Cocoon 5) JBoss integration ? 6) Some cool demo apps 7) How-tos, sample code and tips from people who have already done this kind of stuff with TM4J. I think that (4) will be the framework that provides the ultimate level of flexibility, but (2) and (3) will be simpler frameworks which might allow developers to "get the job done" - I am especially thinking of cases where Velocity/Cocoon is used to do a static transformation of an entire topic map into HTML pages (rather than serving HTML on the fly). (6) will be the way to showcase all of these different ways of doing things - the Velocity/Struts project has a nice set of demos where you can compare the Struts w/ JSP method with the Struts w/ Velocity method - perhaps something similar would be good for tm4web For (0), I think that the existing system could be nicely enhanced with a simple command-line application that combines the processing of one or more topic maps into a single consistent topic map with the actual XSL transformation - the app could also be used to allow the transformation of topic maps from the persistent backends with the stylesheet. Part of this work would be to create an XMLReader implementation for a TopicMap object so that a TopicMap object could be read as a Source for a TRAX transformation. Thoughts ? Is there something else that I have missed from this list ? Cheers, Kal On Sun, 2003-02-02 at 22:16, Martin Stockhammer wrote: > 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 > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Tm4j-users mailing list > Tm4...@li... > https://lists.sourceforge.net/lists/listinfo/tm4j-users > |
|
From: Martin S. <m.s...@we...> - 2003-02-02 22:11:39
|
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 |
|
From: Kal A. <ka...@te...> - 2003-01-30 22:11:15
|
That was, of course ,just a test to see who is awake. The real bug URL is: https://sourceforge.net/tracker/index.php?func=detail&aid=677797&group_id=27895&atid=391879 Cheers, Kal On Thu, 2003-01-30 at 22:01, Kal Ahmed wrote: > Folks, > > Can you please take a quick look at this bug: > > https://sourceforge.net/tracker/index.php?func=detail&aid=671799&group_id=27895&atid=391879 > > and let me know which of the options for fixing this you prefer. I am > tending towards option (2), but if there are other good ideas I am > willing to hear them > > Cheers, > > Kal > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Tm4j-developers mailing list > Tm4...@li... > https://lists.sourceforge.net/lists/listinfo/tm4j-developers > |
|
From: Kal A. <ka...@te...> - 2003-01-30 22:05:07
|
Folks, Can you please take a quick look at this bug: https://sourceforge.net/tracker/index.php?func=detail&aid=671799&group_id=27895&atid=391879 and let me know which of the options for fixing this you prefer. I am tending towards option (2), but if there are other good ideas I am willing to hear them Cheers, Kal |
|
From: Florian G. H. <fg...@bk...> - 2003-01-26 22:54:46
|
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 |
|
From: Jack P. <jac...@th...> - 2003-01-25 15:03:57
|
Kal, I'm not sure that I was actually calling for a massive effort on your part, or, necessarily, on any individual's part to mount the giant horse that would take us into the CMS battlefield. Indeed, what with topic maps, maybe the game isn't content management at all; rather it might be subject management. Rather, I think I was mostly pointing out that, in terms of mind share of users 'out there', we Java jockeys have a long way to go before we appear (appearances are nearly everything, these days) competitive. There are some truly awesome Java-based CMS tools out there, none of which touches topic maps at all. Overall, I return to my original point that there is really little if anything available in Java that one could call a complete Webportal system. I think my point was that your call for the future of TM4Web might be a useful starting point where the target is to enable other projects (e.g. DSpace, Cocoon, etc) to become, um, finished. Cheers Jack At 02:21 PM 1/25/2003 +0000, Kal Ahmed wrote: >Jack, > >Thanks for your reply. While I do agree with you that a simple content >management system is still something that is missing from the open-source >world, and also that topic maps have a role to play in such a system, I am >not sure whether I could commit to starting on such a project myself. The >TM4J core code takes a fair amount of my time in terms of development and >support. A new CMS really requires a technical architect/lead developer who >can commit as much of their free time to it as possible to get off the ground >- just the sheer amount of work that would be needed to make a 0.1 let alone >a 1.0 release of such a system is something that I cannot really contemplate >right now. > >However, what I do think would be a valuable contribution and a step in the >right direction would be to gather together the combined experience of folks >on this list (and others) who have started down the road of using topic maps >as the organising principle for web content. > >I do agree with you that there is alot of the groundwork for a useful CMS >application using TM4J to be built, I'm just not sure whether that should be >the focus of TM4Web, or if it would not be better to create the hooks into >existing web application frameworks that might allow others to develop such a >system. > >However, I'm not closed to the possibility of working on such a system, >nor am >I closed to the possibility of TM4Web turning into such a system, I'm just >sceptical that that would happen without another developer joining with that >as his or her primary focus. > >Cheers, > >Kal > >PS - the Zope topic map system is a project on sourceforge >http://sourceforge.net/projects/ztm - I haven't played with it yet though I >will...perhaps doing so will change my mind! > > >On Thursday 23 January 2003 16:02, Jack Park wrote: > > Kal, you are not even close to "mad" contemplating this. Here is why, in > > my view: > > > > Recently, a bunch of friends and I were treated to a demonstration of Zope > > with Plone. I confess, it was awesome, something any Web developer would > > drool over. I understand there's even a topic map engine for Zope in the > > works. > > > > I was asked how come there isn't something equivalent in Javaland. Well, > > there is, almost, and it is Cocoon, or maybe JBoss, or maybe JBoss/Cocoon. > > But, they are not even close. Here is why I think that is so. > > > > The demonstration was given by a fellow who ostensibly is not a programmer. > > He is a Web developer, probably skilled in HTML and so forth. The issue is > > this: the work is already done. Install Zope, drop Plone into it, and you > > pretty much have nearly everything you need. No need to get involved with > > XML of any kind. Just go to the control panel and set things up the way you > > want them. > > > > I would be more than happy to stand corrected, but for now, in my view, > > there's nothing like that (in terms of completeness) running in Java. If > > Zope gets a potent topic map engine, then the floodgate of topic map > > applications that I think lies waiting to open will do so. > > > > From the standpoint of content management, there are a bunch of really > > slick apps out there (dspace, wynona, etc) all of which are more than ready > > for topic map implementation, none of which is as "light switch simple" as > > the Zope/Plone ensemble. > > > > Therefore, I am very much interested in the kinds of things you are > > speaking about here. Particularly, I look at it this way. > > > > JBoss advertises scalability. Cocoon advertises completeness. Put the two > > together, strip out the unnecessary J2EE stuff, and you're quite close to a > > good starting point. But, where are the applications? There was an article > > on building portals with Cocoon. That's a pretty good start. There's > > supposed to be a Wiki for Cocoon. I haven't seen it working. There's > > supposed to be a blog engine for Cocoon. I haven't seen it working. > > > > 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. > > > > The world (still according to Park) probably needs some of the collective > > sensemaking ideas I have outlined elsewhere (e.g. > > http://www.nexist.org/sc2002/). These should, I think, be built-in > > functionality that resides as part of the topic map facility. > > > > The projects you enumerate below are, to me, clear evidence that we are > > already aimed in the right direction. What's missing? I think what's > > missing is an attempt to integrate those and other emerging projects into a > > light switch easy package. > > > > That's my 0.125 EUROs for the day. > > Cheers > > Jack > > > > At 11:11 AM 1/23/2003 +0000, Kal Ahmed wrote: > > >Apologies for the cross-posting, I just wanted to be sure that I got > > >everyone's attention ;-) > > > > > >A while ago, Florian Haas and Thomas Bauer contributed a package called > > >TM4Web > > >to the TM4J Project. This package contains a set of stylesheets for > > >converting XTM syntax topic maps into a collection of HTML pages using the > > >page-per-topic style of the TM4J.org website. > > > > > >Separately from that work, I had developed a template-based mechanism for > > >creating HTML pages directly from a TM4J TopicMap which works both as a > > >servlet and as a stand-alone application. > > > > > >Separately from that, I have played with Cocoon and the TM4Web stylesheets > > > to create a little sample webapp that uses TM4J APIs to extract topic map > > > fragments and TM4Web stylesheets to create the HTML output in a Cocoon > > > processing pipe. > > > > > >Separately from *that*, Christoph Frolich, Niko Schmuck and Martin > > >Stockhammer > > >are working on TMNav which, while aimed more at the development of GUI > > > tools, has a strong web application component with a WS interface and > > > with a flexible abstraction and rendering process which would work well > > > in a web application. > > > > > >Separately from all of that, I know that a number of people are using TM4J > > > to create web applications using a wide variety of frameworks and > > > toolkits. > > > > > >What we all have in common is that we are creating web applications for > > >presenting and/or modifying topic maps in a browser, but we are taking > > >different approaches with different focusses and different strenghts and > > >weaknesses. > > > > > >My feeling is that this is all good. > > > > > >What I would like to do is to use TM4Web as a banner project for bringing > > >together design approaches; patterns for rendering topic maps; utility > > >classes and sample tools and applications all with the aim of making it > > > easy for developers to find some starting point for their own > > > applications. This is quite a big undertaking and I would like to get an > > > idea about how much support there is for this in the community. > > > > > >Do you think that this approach is a good idea, or would you prefer to see > > >the > > >TM4J project produce a single one-size-fits-all solution for topic maps on > > >the web ? > > > > > >Do you have any experience and/or sample code which you might consider > > >contributing to TM4Web ? > > > > > >Am I just mad for even contemplating this ? (probably) > > > > > >Any thoughts / opinions gratefully received. > > > > > >Cheers, > > > > > >Kal > > > > > >-- > > >Kal Ahmed, techquila.com > > >XML and Topic Map Consultancy > > > > > >e: ka...@te... > > >p: +44 7968 529531 > > >w: www.techquila.com > > > > > > > > > > > >------------------------------------------------------- > > >This SF.NET email is sponsored by: > > >SourceForge Enterprise Edition + IBM + LinuxWorld > > > http://www.vasoftware.com _______________________________________________ > > >Tm4j-developers mailing list > > >Tm4...@li... > > >https://lists.sourceforge.net/lists/listinfo/tm4j-developers > > > > --------------------------------------------------------------------------- > > XML Topic Maps: Creating and Using Topic Maps for the Web. > > Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor > > > > Build smarter kids globally and you reduce the need for smarter bombs. > >-- >Kal Ahmed, techquila.com >XML and Topic Map Consultancy > >e: ka...@te... >p: +44 7968 529531 >w: www.techquila.com --------------------------------------------------------------------------- XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor Build smarter kids globally and you reduce the need for smarter bombs. |
|
From: Kal A. <ka...@te...> - 2003-01-25 14:03:06
|
Jack, Thanks for your reply. While I do agree with you that a simple content=20 management system is still something that is missing from the open-source= =20 world, and also that topic maps have a role to play in such a system, I a= m=20 not sure whether I could commit to starting on such a project myself. Th= e=20 TM4J core code takes a fair amount of my time in terms of development and= =20 support. A new CMS really requires a technical architect/lead developer w= ho=20 can commit as much of their free time to it as possible to get off the gr= ound=20 - just the sheer amount of work that would be needed to make a 0.1 let al= one=20 a 1.0 release of such a system is something that I cannot really contempl= ate=20 right now. However, what I do think would be a valuable contribution and a step in t= he=20 right direction would be to gather together the combined experience of fo= lks=20 on this list (and others) who have started down the road of using topic m= aps=20 as the organising principle for web content. I do agree with you that there is alot of the groundwork for a useful CMS= =20 application using TM4J to be built, I'm just not sure whether that should= be=20 the focus of TM4Web, or if it would not be better to create the hooks int= o=20 existing web application frameworks that might allow others to develop su= ch a=20 system. However, I'm not closed to the possibility of working on such a system, n= or am=20 I closed to the possibility of TM4Web turning into such a system, I'm jus= t=20 sceptical that that would happen without another developer joining with t= hat=20 as his or her primary focus. Cheers, Kal PS - the Zope topic map system is a project on sourceforge=20 http://sourceforge.net/projects/ztm - I haven't played with it yet though= I=20 will...perhaps doing so will change my mind!=20 On Thursday 23 January 2003 16:02, Jack Park wrote: > Kal, you are not even close to "mad" contemplating this. Here is why, = in > my view: > > Recently, a bunch of friends and I were treated to a demonstration of Z= ope > with Plone. I confess, it was awesome, something any Web developer wou= ld > drool over. I understand there's even a topic map engine for Zope in th= e > works. > > I was asked how come there isn't something equivalent in Javaland. Wel= l, > there is, almost, and it is Cocoon, or maybe JBoss, or maybe JBoss/Coco= on. > But, they are not even close. Here is why I think that is so. > > The demonstration was given by a fellow who ostensibly is not a program= mer. > He is a Web developer, probably skilled in HTML and so forth. The issue= is > this: the work is already done. Install Zope, drop Plone into it, and y= ou > pretty much have nearly everything you need. No need to get involved wi= th > XML of any kind. Just go to the control panel and set things up the way= you > want them. > > I would be more than happy to stand corrected, but for now, in my view, > there's nothing like that (in terms of completeness) running in Java. = If > Zope gets a potent topic map engine, then the floodgate of topic map > applications that I think lies waiting to open will do so. > > From the standpoint of content management, there are a bunch of really > slick apps out there (dspace, wynona, etc) all of which are more than r= eady > for topic map implementation, none of which is as "light switch simple"= as > the Zope/Plone ensemble. > > Therefore, I am very much interested in the kinds of things you are > speaking about here. Particularly, I look at it this way. > > JBoss advertises scalability. Cocoon advertises completeness. Put the t= wo > together, strip out the unnecessary J2EE stuff, and you're quite close = to a > good starting point. But, where are the applications? There was an art= icle > on building portals with Cocoon. That's a pretty good start. There's > supposed to be a Wiki for Cocoon. I haven't seen it working. There's > supposed to be a blog engine for Cocoon. I haven't seen it working. > > 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. > > The world (still according to Park) probably needs some of the collecti= ve > sensemaking ideas I have outlined elsewhere (e.g. > http://www.nexist.org/sc2002/). These should, I think, be built-in > functionality that resides as part of the topic map facility. > > The projects you enumerate below are, to me, clear evidence that we are > already aimed in the right direction. What's missing? I think what's > missing is an attempt to integrate those and other emerging projects in= to a > light switch easy package. > > That's my 0.125 EUROs for the day. > Cheers > Jack > > At 11:11 AM 1/23/2003 +0000, Kal Ahmed wrote: > >Apologies for the cross-posting, I just wanted to be sure that I got > >everyone's attention ;-) > > > >A while ago, Florian Haas and Thomas Bauer contributed a package calle= d > >TM4Web > >to the TM4J Project. This package contains a set of stylesheets for > >converting XTM syntax topic maps into a collection of HTML pages using= the > >page-per-topic style of the TM4J.org website. > > > >Separately from that work, I had developed a template-based mechanism = for > >creating HTML pages directly from a TM4J TopicMap which works both as = a > >servlet and as a stand-alone application. > > > >Separately from that, I have played with Cocoon and the TM4Web stylesh= eets > > to create a little sample webapp that uses TM4J APIs to extract topic= map > > fragments and TM4Web stylesheets to create the HTML output in a Cocoo= n > > processing pipe. > > > >Separately from *that*, Christoph Frolich, Niko Schmuck and Martin > >Stockhammer > >are working on TMNav which, while aimed more at the development of GUI > > tools, has a strong web application component with a WS interface and > > with a flexible abstraction and rendering process which would work we= ll > > in a web application. > > > >Separately from all of that, I know that a number of people are using = TM4J > > to create web applications using a wide variety of frameworks and > > toolkits. > > > >What we all have in common is that we are creating web applications fo= r > >presenting and/or modifying topic maps in a browser, but we are taking > >different approaches with different focusses and different strenghts a= nd > >weaknesses. > > > >My feeling is that this is all good. > > > >What I would like to do is to use TM4Web as a banner project for bring= ing > >together design approaches; patterns for rendering topic maps; utility > >classes and sample tools and applications all with the aim of making i= t > > easy for developers to find some starting point for their own > > applications. This is quite a big undertaking and I would like to ge= t an > > idea about how much support there is for this in the community. > > > >Do you think that this approach is a good idea, or would you prefer to= see > >the > >TM4J project produce a single one-size-fits-all solution for topic map= s on > >the web ? > > > >Do you have any experience and/or sample code which you might consider > >contributing to TM4Web ? > > > >Am I just mad for even contemplating this ? (probably) > > > >Any thoughts / opinions gratefully received. > > > >Cheers, > > > >Kal > > > >-- > >Kal Ahmed, techquila.com > >XML and Topic Map Consultancy > > > >e: ka...@te... > >p: +44 7968 529531 > >w: www.techquila.com > > > > > > > >------------------------------------------------------- > >This SF.NET email is sponsored by: > >SourceForge Enterprise Edition + IBM + LinuxWorld > > http://www.vasoftware.com ___________________________________________= ____ > >Tm4j-developers mailing list > >Tm4...@li... > >https://lists.sourceforge.net/lists/listinfo/tm4j-developers > > -----------------------------------------------------------------------= ---- > XML Topic Maps: Creating and Using Topic Maps for the Web. > Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor > > Build smarter kids globally and you reduce the need for smarter bombs. --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Jack P. <jac...@th...> - 2003-01-23 16:04:15
|
Kal, you are not even close to "mad" contemplating this. Here is why, in my view: Recently, a bunch of friends and I were treated to a demonstration of Zope with Plone. I confess, it was awesome, something any Web developer would drool over. I understand there's even a topic map engine for Zope in the works. I was asked how come there isn't something equivalent in Javaland. Well, there is, almost, and it is Cocoon, or maybe JBoss, or maybe JBoss/Cocoon. But, they are not even close. Here is why I think that is so. The demonstration was given by a fellow who ostensibly is not a programmer. He is a Web developer, probably skilled in HTML and so forth. The issue is this: the work is already done. Install Zope, drop Plone into it, and you pretty much have nearly everything you need. No need to get involved with XML of any kind. Just go to the control panel and set things up the way you want them. I would be more than happy to stand corrected, but for now, in my view, there's nothing like that (in terms of completeness) running in Java. If Zope gets a potent topic map engine, then the floodgate of topic map applications that I think lies waiting to open will do so. From the standpoint of content management, there are a bunch of really slick apps out there (dspace, wynona, etc) all of which are more than ready for topic map implementation, none of which is as "light switch simple" as the Zope/Plone ensemble. Therefore, I am very much interested in the kinds of things you are speaking about here. Particularly, I look at it this way. JBoss advertises scalability. Cocoon advertises completeness. Put the two together, strip out the unnecessary J2EE stuff, and you're quite close to a good starting point. But, where are the applications? There was an article on building portals with Cocoon. That's a pretty good start. There's supposed to be a Wiki for Cocoon. I haven't seen it working. There's supposed to be a blog engine for Cocoon. I haven't seen it working. 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. The world (still according to Park) probably needs some of the collective sensemaking ideas I have outlined elsewhere (e.g. http://www.nexist.org/sc2002/). These should, I think, be built-in functionality that resides as part of the topic map facility. The projects you enumerate below are, to me, clear evidence that we are already aimed in the right direction. What's missing? I think what's missing is an attempt to integrate those and other emerging projects into a light switch easy package. That's my 0.125 EUROs for the day. Cheers Jack At 11:11 AM 1/23/2003 +0000, Kal Ahmed wrote: >Apologies for the cross-posting, I just wanted to be sure that I got >everyone's attention ;-) > >A while ago, Florian Haas and Thomas Bauer contributed a package called >TM4Web >to the TM4J Project. This package contains a set of stylesheets for >converting XTM syntax topic maps into a collection of HTML pages using the >page-per-topic style of the TM4J.org website. > >Separately from that work, I had developed a template-based mechanism for >creating HTML pages directly from a TM4J TopicMap which works both as a >servlet and as a stand-alone application. > >Separately from that, I have played with Cocoon and the TM4Web stylesheets to >create a little sample webapp that uses TM4J APIs to extract topic map >fragments and TM4Web stylesheets to create the HTML output in a Cocoon >processing pipe. > >Separately from *that*, Christoph Frolich, Niko Schmuck and Martin >Stockhammer >are working on TMNav which, while aimed more at the development of GUI tools, >has a strong web application component with a WS interface and with a >flexible abstraction and rendering process which would work well in a web >application. > >Separately from all of that, I know that a number of people are using TM4J to >create web applications using a wide variety of frameworks and toolkits. > >What we all have in common is that we are creating web applications for >presenting and/or modifying topic maps in a browser, but we are taking >different approaches with different focusses and different strenghts and >weaknesses. > >My feeling is that this is all good. > >What I would like to do is to use TM4Web as a banner project for bringing >together design approaches; patterns for rendering topic maps; utility >classes and sample tools and applications all with the aim of making it easy >for developers to find some starting point for their own applications. This >is quite a big undertaking and I would like to get an idea about how much >support there is for this in the community. > >Do you think that this approach is a good idea, or would you prefer to see >the >TM4J project produce a single one-size-fits-all solution for topic maps on >the web ? > >Do you have any experience and/or sample code which you might consider >contributing to TM4Web ? > >Am I just mad for even contemplating this ? (probably) > >Any thoughts / opinions gratefully received. > >Cheers, > >Kal > >-- >Kal Ahmed, techquila.com >XML and Topic Map Consultancy > >e: ka...@te... >p: +44 7968 529531 >w: www.techquila.com > > > >------------------------------------------------------- >This SF.NET email is sponsored by: >SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com >_______________________________________________ >Tm4j-developers mailing list >Tm4...@li... >https://lists.sourceforge.net/lists/listinfo/tm4j-developers --------------------------------------------------------------------------- XML Topic Maps: Creating and Using Topic Maps for the Web. Addison-Wesley. Jack Park, Editor. Sam Hunting, Technical Editor Build smarter kids globally and you reduce the need for smarter bombs. |
|
From: Kal A. <ka...@te...> - 2003-01-23 10:54:21
|
Apologies for the cross-posting, I just wanted to be sure that I got=20 everyone's attention ;-) A while ago, Florian Haas and Thomas Bauer contributed a package called T= M4Web=20 to the TM4J Project. This package contains a set of stylesheets for=20 converting XTM syntax topic maps into a collection of HTML pages using th= e=20 page-per-topic style of the TM4J.org website. Separately from that work, I had developed a template-based mechanism for= =20 creating HTML pages directly from a TM4J TopicMap which works both as a=20 servlet and as a stand-alone application. Separately from that, I have played with Cocoon and the TM4Web stylesheet= s to=20 create a little sample webapp that uses TM4J APIs to extract topic map=20 fragments and TM4Web stylesheets to create the HTML output in a Cocoon=20 processing pipe. Separately from *that*, Christoph Frolich, Niko Schmuck and Martin Stockh= ammer=20 are working on TMNav which, while aimed more at the development of GUI to= ols,=20 has a strong web application component with a WS interface and with a=20 flexible abstraction and rendering process which would work well in a web= =20 application. Separately from all of that, I know that a number of people are using TM4= J to=20 create web applications using a wide variety of frameworks and toolkits. What we all have in common is that we are creating web applications for=20 presenting and/or modifying topic maps in a browser, but we are taking=20 different approaches with different focusses and different strenghts and=20 weaknesses. My feeling is that this is all good. What I would like to do is to use TM4Web as a banner project for bringing= =20 together design approaches; patterns for rendering topic maps; utility=20 classes and sample tools and applications all with the aim of making it e= asy=20 for developers to find some starting point for their own applications. T= his=20 is quite a big undertaking and I would like to get an idea about how much= =20 support there is for this in the community. Do you think that this approach is a good idea, or would you prefer to se= e the=20 TM4J project produce a single one-size-fits-all solution for topic maps o= n=20 the web ? Do you have any experience and/or sample code which you might consider=20 contributing to TM4Web ? Am I just mad for even contemplating this ? (probably) Any thoughts / opinions gratefully received. Cheers, Kal =20 --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2003-01-15 20:33:22
|
Hi all, Just to let you know, I have created a new branch in the CVS repository. = =46rom=20 now on, bug-fixes for 0.8.0 should be made in the branch R_0_8_0_patches.= =20 Development towards 0.9.0 should be made in the head branch. Cheers, Kal -- Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-12-16 21:49:33
|
I started having a go at an initial implementation of the re-organised fa= ctory=20 methods and it turned out to be a bit easier than I expected - by making = use=20 of the existing factory methods I was able to implement factory methods o= n=20 the objects quite easily. Can you take a look at these updated APIs and see what you think.=20 Note 1: I have only done a regression test so far - I will need to update= the=20 test code to test the new factory methods later if we decide that this is= a=20 better API. Note 2: There is scope for more convenience factory methods such as Rene=20 discussed in his emails. If the general opinion is in favour of this new=20 style of API, then I shall add convenienve factory methods as well (e.g.=20 Topic.addOccurrence(String id, Topic type, Locator resource),=20 Topic.addOccurrence(String id, Topic type, Locator resource, Scope scope)= =20 etc.) Cheers, Kal On Monday 16 December 2002 18:39, Kal Ahmed wrote: > On Monday 16 December 2002 17:43, Ren...@da... wrote= : > > ReHi Kal, > > > > In general it sounds good and I am really looking forward to these > > changes to see how your API will work together with our research proj= ect. > > > > In the end it is your decision when to do the refactoring considering > > these conceptional aspects. But due to my experiences it is advisable= to > > do them as early as possible. The more code you have and the more > > backends are implemented the bigger and more complex are the changes = you > > will have to do. If I where you I would even go further. I would fix = the > > memory backend first until it would seem perfect to me. Afterward I w= ould > > adapt the results to the other backends. If you consider the resource > > time, I think you would need less of it this way. But you are the man= ager > > of this project and that is why you make the decisions. > > It is a balancing act between developing the features that people have > requested (such as RDBMS persistance); the features I want (like the > unified topic map); and spending time on the other work such as API > improvements; documentation improvements and so on. There is a cost in > changing the API all the time, but on the flip-side, working with > persistent storage mechanisms such as Ozone/Hibernate has made me > reconsider a number of things about the original in-memory-only API, so= it > is sometimes beneficial to be forced to implement against both in-memor= y > and persistent back-ends. > > > By the way - I have another point which can be improved, I think ;-) > > > > When creating a BaseName for Example you use the method > > createBaseName(String id). This method will use the Constructor publi= c > > BaseName(TopicMap tm, String id) or something like that. All in all y= ou > > can only create a BaseName with an id. If there is the wish to add a > > BaseNameString you have to add it with the add method of BaseName. I > > think the user is not interrested in the id mostly when creating a > > BaseName. What is interressting for him is the BaseNameString. Someti= mes > > he does not want to concern about the id at all. That is why you shou= ld > > give him the opportunity to let the API generate the id. There could = be > > two methods. > > > > createBaseName(parent) if the user is not interessted in the id > > and > > createBaseName(String id, parent) if the user wants to choose an id > > himself and > > createBaseNameString(String baseNameString, parent); > > > > or later: > > Topic.createBaseName() > > and > > Topic.createBaseName(String id) > > and > > BaseName.createBaseNameString(String baseNameString) > > Those are good suggestions to carry forward to the next re-working of t= he > API. Although I think that I would treat the baseNameString as a proper= ty > of BaseName, not as a child object. That means that you would have > BaseName.setBaseNameString() (or as it is currently called > BaseName.setData()). > > > The same is also true of other child elements of a Topic Map which > > usability could be improved. But this can wait until the TM API > > interfaces are implemented, because you will have to change this > > afterwards again. What I consider to be the most important thing now,= is > > to adapt TM API interfaces to TM4J. > > It should probably be done at the same time, though I am still thinking > that this should be after 0.8.0. > > However, I do not see any reason why the time between 0.8.0 and 0.9.0 > should be as long as it has been between 0.7.0 and 0.8.0. > > Cheers, > > Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: Kal A. <ka...@te...> - 2002-12-16 18:08:21
|
On Monday 16 December 2002 17:43, Ren...@da... wrote: > ReHi Kal, > > In general it sounds good and I am really looking forward to these chan= ges > to see how your API will work together with our research project. > > In the end it is your decision when to do the refactoring considering t= hese > conceptional aspects. But due to my experiences it is advisable to do t= hem > as early as possible. The more code you have and the more backends are > implemented the bigger and more complex are the changes you will have t= o > do. If I where you I would even go further. I would fix the memory back= end > first until it would seem perfect to me. Afterward I would adapt the > results to the other backends. If you consider the resource time, I thi= nk > you would need less of it this way. But you are the manager of this pro= ject > and that is why you make the decisions. > It is a balancing act between developing the features that people have=20 requested (such as RDBMS persistance); the features I want (like the unif= ied=20 topic map); and spending time on the other work such as API improvements;= =20 documentation improvements and so on. There is a cost in changing the API= all=20 the time, but on the flip-side, working with persistent storage mechanism= s=20 such as Ozone/Hibernate has made me reconsider a number of things about t= he=20 original in-memory-only API, so it is sometimes beneficial to be forced t= o=20 implement against both in-memory and persistent back-ends. > By the way - I have another point which can be improved, I think ;-) > > When creating a BaseName for Example you use the method > createBaseName(String id). This method will use the Constructor public > BaseName(TopicMap tm, String id) or something like that. All in all you= can > only create a BaseName with an id. If there is the wish to add a > BaseNameString you have to add it with the add method of BaseName. I th= ink > the user is not interrested in the id mostly when creating a BaseName. = What > is interressting for him is the BaseNameString. Sometimes he does not w= ant > to concern about the id at all. That is why you should give him the > opportunity to let the API generate the id. There could be two methods. > > createBaseName(parent) if the user is not interessted in the id > and > createBaseName(String id, parent) if the user wants to choose an id him= self > and > createBaseNameString(String baseNameString, parent); > > or later: > Topic.createBaseName() > and > Topic.createBaseName(String id) > and > BaseName.createBaseNameString(String baseNameString) > Those are good suggestions to carry forward to the next re-working of the= API.=20 Although I think that I would treat the baseNameString as a property of=20 BaseName, not as a child object. That means that you would have=20 BaseName.setBaseNameString() (or as it is currently called=20 BaseName.setData()). > The same is also true of other child elements of a Topic Map which > usability could be improved. But this can wait until the TM API interfa= ces > are implemented, because you will have to change this afterwards again. > What I consider to be the most important thing now, is to adapt TM API > interfaces to TM4J. > It should probably be done at the same time, though I am still thinking t= hat=20 this should be after 0.8.0. However, I do not see any reason why the time between 0.8.0 and 0.9.0 sho= uld=20 be as long as it has been between 0.7.0 and 0.8.0. Cheers, Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: <Ren...@da...> - 2002-12-16 17:43:07
|
ReHi Kal,
In general it sounds good and I am really looking forward to these chan=
ges to=20
see how your API will work together with our research project.
In the end it is your decision when to do the refactoring considering t=
hese=20
conceptional aspects. But due to my experiences it is advisable to do t=
hem as=20
early as possible. The more code you have and the more backends are imp=
lemented=20
the bigger and more complex are the changes you will have to do. If I w=
here you=20
I would even go further. I would fix the memory backend first until it =
would=20
seem perfect to me. Afterward I would adapt the results to the other ba=
ckends.=20
If you consider the resource time, I think you would need less of it th=
is way.=20
But you are the manager of this project and that is why you make the de=
cisions.
By the way - I have another point which can be improved, I think ;-)
When creating a BaseName for Example you use the method createBaseName(=
String=20
id). This method will use the Constructor public BaseName(TopicMap tm, =
String=20
id) or something like that. All in all you can only create a BaseName w=
ith an=20
id. If there is the wish to add a BaseNameString you have to add it wit=
h the=20
add method of BaseName. I think the user is not interrested in the id m=
ostly=20
when creating a BaseName. What is interressting for him is the BaseName=
String.=20
Sometimes he does not want to concern about the id at all. That is why =
you=20
should give him the opportunity to let the API generate the id. There c=
ould be=20
two methods.
createBaseName(parent) if the user is not interessted in the id
and
createBaseName(String id, parent) if the user wants to choose an id him=
self
and=20
createBaseNameString(String baseNameString, parent);
or later:=20
Topic.createBaseName()
and=20
Topic.createBaseName(String id)
and
BaseName.createBaseNameString(String baseNameString)
The same is also true of other child elements of a Topic Map which usa=
bility=20
could be improved. But this can wait until the TM API interfaces are=20
implemented, because you will have to change this afterwards again. Wha=
t I=20
consider to be the most important thing now, is to adapt TM API interfa=
ces to=20
TM4J.
Greetings to all...
Ren=E9 Freude (Ren...@da...)=20
DaimlerChrysler AG=20
Research - Information & Communication=20
Software Technologies / Methods & Tools=20
(RIC/SM)=20
Berlin / Germany =20
=20
ka...@te...
16.12.02 17:50
Bitte antworten an kal
=09
=09
=20
An: Rene Freude/FT/DCAG/DCX@wK-EMEA2
Kopie: tm4...@li...
Thema: Re: TopicMapFactory refactoring
Hi Rene,
On Monday 16 December 2002 13:12, Ren...@da... wrote=
:
> Hello,
>
> I am that impertinent to write to the developers mailinglist, because=
I
> think this topic is placed best here. At first I want to epress my th=
anks
> to Kal Ahmed for starting to fix some issues of the TopicMapFactory t=
hat
> fast. That's why I can wait a little bit with my implementations and =
do not
> have to refactor code myself ;)
>
:-) Thats a good thing!
> I am convinced with the new changes the whole process of creating a
> TopicMap will be more consistent, comfortable and intuitive. Neverthe=
less I
> think that this changes can not be the final solution. If I had unde=
rstood
> Kal Ahmed right, he is also thinking this way. He mentioned two or th=
ree
> alternatives he is considering to be suitable. Over the weekend I als=
o
> thought a little bit about this topic and came to a conclusion:
>
> I think the best variant is already realized in the TM API interfaces=
.
> Every single TopicMapObject (except from leaves) has one or more fact=
ory
> methods to create its direct childs and/or add methods for references=
like
> the subject indicator. The benefit would not only consist of an extre=
me
> increase of usability but also of the fact that some unnecessary mist=
akes
> on part of the user of the TM4J API could be entirely abolished:
>
> - Using a wrong factory when creating a TopicMapObject
> - Adding a Topic that does not fit to a special TopicMap
> ...
>
Yep, I think that you are right in this analysis. I think that also the=
=20
existing implementations should be made more robust to throw exceptions=
when=20
attempting to combine two objects from different topic maps (e.g. when =
trying=20
to call a.setType(b) where a is a Topic from TopicMap1 and B is a Topic=
from=20
TopicMap2).
> Consequently the number of Exception are thrown while the creating pr=
ocess
> of a TopicMap could be reduced to a tolerable level ;).
> But I also see that you have much more to do than refactoring your Co=
de.
>
Yes there would be. I think that in the interests of making an 0.8.0 re=
lease=20
soon so that people can start to play with the two new back-ends and gi=
ve=20
some feedback/bug reports on those, I will probably not implement this =
for=20
0.8.0, but will make it a task for 0.9.0.
How does that sound ?
Cheers,
Kal
--=20
Kal Ahmed, techquila.com
XML and Topic Map Consultancy
e: ka...@te...
p: +44 7968 529531
w: www.techquila.com
=
|
|
From: Kal A. <ka...@te...> - 2002-12-16 16:49:38
|
Hi Rene, On Monday 16 December 2002 13:12, Ren...@da... wrote: > Hello, > > I am that impertinent to write to the developers mailinglist, because I > think this topic is placed best here. At first I want to epress my than= ks > to Kal Ahmed for starting to fix some issues of the TopicMapFactory tha= t > fast. That's why I can wait a little bit with my implementations and do= not > have to refactor code myself ;) > :-) Thats a good thing! > I am convinced with the new changes the whole process of creating a > TopicMap will be more consistent, comfortable and intuitive. Neverthele= ss I > think that this changes can not be the final solution. If I had unders= tood > Kal Ahmed right, he is also thinking this way. He mentioned two or thre= e > alternatives he is considering to be suitable. Over the weekend I also > thought a little bit about this topic and came to a conclusion: > > I think the best variant is already realized in the TM API interfaces. > Every single TopicMapObject (except from leaves) has one or more factor= y > methods to create its direct childs and/or add methods for references l= ike > the subject indicator. The benefit would not only consist of an extreme > increase of usability but also of the fact that some unnecessary mistak= es > on part of the user of the TM4J API could be entirely abolished: > > - Using a wrong factory when creating a TopicMapObject > - Adding a Topic that does not fit to a special TopicMap > ... > Yep, I think that you are right in this analysis. I think that also the=20 existing implementations should be made more robust to throw exceptions w= hen=20 attempting to combine two objects from different topic maps (e.g. when tr= ying=20 to call a.setType(b) where a is a Topic from TopicMap1 and B is a Topic f= rom=20 TopicMap2). > Consequently the number of Exception are thrown while the creating proc= ess > of a TopicMap could be reduced to a tolerable level ;). > But I also see that you have much more to do than refactoring your Code= =2E > Yes there would be. I think that in the interests of making an 0.8.0 rele= ase=20 soon so that people can start to play with the two new back-ends and give= =20 some feedback/bug reports on those, I will probably not implement this fo= r=20 0.8.0, but will make it a task for 0.9.0. How does that sound ? Cheers, Kal --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: ka...@te... p: +44 7968 529531 w: www.techquila.com |
|
From: <Ren...@da...> - 2002-12-16 13:12:43
|
Hello, I am that impertinent to write to the developers mailinglist, because I= think=20 this topic is placed best here. At first I want to epress my thanks to = Kal=20 Ahmed for starting to fix some issues of the TopicMapFactory that fast.= That's=20 why I can wait a little bit with my implementations and do not have to = refactor=20 code myself ;) I am convinced with the new changes the whole process of creating a Top= icMap=20 will be more consistent, comfortable and intuitive. Nevertheless I thi= nk that=20 this changes can not be the final solution. If I had understood Kal Ahm= ed=20 right, he is also thinking this way. He mentioned two or three alternat= ives he=20 is considering to be suitable. Over the weekend I also thought a little= bit=20 about this topic and came to a conclusion: I think the best variant is already realized in the TM API interfaces. = Every=20 single TopicMapObject (except from leaves) has one or more factory meth= ods to=20 create its direct childs and/or add methods for references like the sub= ject=20 indicator. The benefit would not only consist of an extreme increase of= =20 usability but also of the fact that some unnecessary mistakes on part o= f the=20 user of the TM4J API could be entirely abolished: - Using a wrong factory when creating a TopicMapObject - Adding a Topic that does not fit to a special TopicMap ... Consequently the number of Exception are thrown while the creating proc= ess of a=20 TopicMap could be reduced to a tolerable level ;).=20 But I also see that you have much more to do than refactoring your Code= . Greetings to all... =20 Ren=E9 Freude (Ren...@da...)=20 DaimlerChrysler AG=20 Research - Information & Communication=20 Software Technologies / Methods & Tools=20 (RIC/SM)=20 Berlin / Germany = |
|
From: <Ren...@da...> - 2002-12-16 13:06:14
|
Hello, I am that impertinent to write to the developers mailinglist, because I= think=20 this topic is placed best here. At first I want to epress my thanks to = Kal=20 Ahmed for starting to fix some issues of the TopicMapFactory that fast.= That's=20 why I can wait a little bit with my implementations and do not have to = refactor=20 code myself ;) I am convinced with the new changes the whole process of creating a Top= icMap=20 will be more consistent, comfortable and intuitive. Nevertheless I thi= nk that=20 this changes can not be the final solution. If I had understood Kal Ahm= ed=20 right, he is also thinking this way. He mentioned two or three alternat= ives he=20 is considering to be suitable. Over the weekend I also thought a little= bit=20 about this topic and came to a conclusion: I think the best variant is already realized in the TM API interfaces. = Every=20 single TopicMapObject (except from leaves) has one or more factory meth= ods to=20 create its direct childs and/or add methods for references like the sub= ject=20 indicator. The benefit would not only consist of an extreme increase of= =20 usability but also of the fact that some unnecessary mistakes on part o= f the=20 user of the TM4J API could be entirely abolished: - Using a wrong factory when creating a TopicMapObject - Adding a Topic that does not fit to a special TopicMap ... Consequently the number of Exception are thrown while the creating proc= ess of a=20 TopicMap could be reduced to a tolerable level ;).=20 But I also see that you have much more to do than refactoring your Code= . Greetings to all... =20 Ren=E9 Freude (Ren...@da...)=20 DaimlerChrysler AG=20 Research - Information & Communication=20 Software Technologies / Methods & Tools=20 (RIC/SM)=20 Berlin / Germany = |
153 messages has been excluded from this view by a project administrator.
