Re: [Xweb-developers] Re: Reactivating development

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

murphee (Werner Schuster) wrote:

> Peter Becker wrote:
>
>> Hendrik Lipka wrote:
>> The point I want to make is that Ant is a developers tool and that 
>> the XWeb integration needed in this context seems to be only the XWeb 
>> task for Ant. The frontend I imagine would be more for someone 
>> setting up a small website without many IT skills -- I suspect 
>> Webbuilder has a different target audience,
>
>
> Not really; it was actually designed to be customizable for all kinds
> of target audiences;
> The idea behind using Ant was not so much to appeal to developers,
> but to have a build process that is as open as possible;
> Don't think of Ant (in Webbuilder) as the developers tool Ant, but as...
> well call it an "API" for a build process; this makes it easy for
> Plugins or DocumentTypes to add their own tasks to the build process;
> they have the wide variety of Ant tasks at their disposal; another
> advantage is to allow advanced users to modify the build process
> themselves (by modifying the build file)... or to allow them
> to fix the build file in case Webbuilder has messed it up;

That would require XWeb to be able to call Ant-tasks, wouldn't it? That 
probably wouldn't be too hard to add, but I wonder about a particular 
scenario were it is really helpful.

> In Webbuilder, the user actually doesn't see Ant itself (or does not
> have to take notice of it); the user just hits deploy and the website
> gets generated and uploaded;

This sounds more like the opposite thing: Ant calling XWeb. This would 
be quite helpful in many situations.

>
>
>
> > also I think that audience is hard to target with a GUI.
>
> Not necessarily; one aspect of Webbuilder was to allow for DocumentTypes
> to come with their own GUI; ie. the FAQ DocumentType came with the FAQ
> XSLT Stylesheet (I think stol^H^H^H^Hcopied from XWeb) and a simple
> GUI that allows for easily entering and modifying the FAQ list;
> the point is, that the FAQs are stored in an XML file; even with a
> good editor (== vi) you would have a lot of overhead writing the file
> yourself; with the tool, you would not have to look at the XML file;
>
> Or imagine a DocumentType "NewsList", where you enter the news item
> in a GUI and hit "deploy"; the GUI would slap a timestamp on the news 
> item, update your RSS file and then arrange for a Rebuild of the Website;

My ideal solution would be along the lines of XMetal, where you get some 
WYSINWYG interface for XML files, with extra bits of GUI defined for a 
particular XML format (in addition to schema and stylesheet). But that's 
another story :-) I wonder if we could do something with configuration 
Beans, storing the parameters of the stylesheet and the important bits 
of CSS for a format. Then we could do a BeanBox-like approach for the GUI.

> > Just look at how many people still code Java with vi or
>
>> Emacs ;-) I never used much in terms of IDEs for C++, but with Java 
>> and Refactoring it is a bit different.
>
>
> And don't forget JUnit integration... that's one of the best features
> in Eclipse;

Yes, also it doesn't help XWeb yet ;-) Gotta fix that, too.

  Peter