Re: [Xweb-developers] Reactivating development

[Peter B. <pe...@pe...>]

murphee (Werner Schuster) wrote:

> Peter Becker wrote:
>
> Hey, great to see some action in the Xweb project again;
>
>
>> Other things I'd like to see:
>> - globbing and regexp for <entryset>s and <fileset>s -- that should 
>> match things like "*.xml" to "*.html" conversions
>
>
> thats great; I suppose it would be possible to bulk-copy whole 
> directories of files instead of having to copy them individually;

Yes, that's already in CVS -- see the other thread for the syntax. 
Things might be changed slightly, though -- esp. the $1 vs. {$1} bit.

>> - support for more operations, e.g. JTidy and FOP, maybe Freemarker 
>> (http://freemarker.sourceforge.net/) or (rather later) things similar 
>> to this: http://www.mullassery.com/software/ANT/index.jsp or this: 
>> http://www.oopsconsultancy.com/software/xmltask.html -- I wonder if 
>> integrating Ant tasks in general would be hard.
>
>
> Well, how about making more use of Ant for XWeb; mostly for dependancy
> checking; maybe split up the processing model upon several Ant tasks
> that can then be used;

I thought about the idea of integrating XWeb into Ant, but I don't think 
it will work. Of course you could call XWeb from withing Ant and Ant 
tasks from XWeb, but Ant seems to be way more file-based than I'd like 
to be in XWeb. Take the way adding the navigation works for example: the 
DOM is constantly changed and copy into the input streams of the XSLT 
process -- I don't see that in the Ant environment.

>
>> - a large refactoring towards a process-oriented model with at least 
>> two iterations through the chains (prepare, do)
>
>
> Some dependancy checking would be great; mostly to allow incremental
> builds instead of the monolithic full rebuilds each time;
>
>
>> Jon wants to have a go at the frontend bit, at least some tree 
>> manipulations with a text editor pane, 
>
>
> There is also my 2 year old (currently not active) project called
> Webbuilder, basically a GUI for XWeb. At
> http://www.angelfire.com/co/werners/developerzone/webbuilder.html
> you can get the tar.gz and some overview of the structure;
> Its about 2 years old, so I suppose the code is not uptodate.
> But it can manipulate Xweb files (as far as I remember);

Yes, that was one of the more advanced tries. And there was the Mozilla 
plugin and my own attempt.

Your bus described in the presentation -- is that a Bean InfoBus?

>
> One point I wanted to do was use Ant extensively, for preprocessing,
> postprocessing and for deployment; the Webbuilder Archive contains
> a sample project.xml that does this (I think deployment only);
> it also contains an Ant Xweb task, that does not really do anything
> besides call XWeb.main();

Ah -- I thought I remembered something about an Ant task for XWeb. My 
memory is like these things you make tea with.

>
> The basic idea of Webbuilder was to allow users to manipulate
> the Xweb tree and also manipulate the build process (which is
> realized with Ant);

What exactly does Ant do in this? The deployment/upload bit is obvious, 
but I am not sure what else Ant could do. But that might be my lack of 
imagination :-)

>
> Webbuilder is only a prototype, but if there is interest in the thing,
> I could put it on Sourceforge and do some work on it again;

I'd rather like to see it as a part of XWeb -- the masterplan has always 
been to replace NetObjects Fusion :-) And I don't see enough resources 
to run multiple frontends, but who knows -- sometimes people pop up out 
of a sudden. I'm easy -- if you want your own project that's fine, too. 
It just seems better for pulicity purposes to have just one.

>
> Oh yeah... the changes in Xweb might some day also fix the problem
> with creating Websites that use relative links, that would really
> be useful for creating local documentation etc.

Yes, I didn't forget that feature request. It definitely makes sense, 
but at the moment it would mean manipulating large parts of the DOM 
again and again. Although -- not necessarily. Thinking about it again I 
just think simple string comparison of the absolute locations could do 
the trick. Can someone comment on this pseudocode (it is late night, I 
am not sure anymore if I make sense):

Input: two absolute paths, one the current position, one the target
1) strip both target and source of the common start
2) add ".." + File.separator n-times in front of the target, where n is 
the number of File.separators in the source

Similarly and safer you could do that with File.getParent(), dump all 
parents on a stack, find the deepest common parent, then add ".."s when 
going down the source side and afterwards the directory names when going 
down the target side.

Might give it a try if it still seems sensible tomorrow.

  Peter