xweb-developers — For people working on the program itself.

[Xweb-developers] gui for cv.xthml

[Dennis D. <dda...@ma...>]

Hello
I've put together a config/application file for creating a CV form using
xybrix. Xybrix is available at www.jbrix.org and at sourceforge as well.

At this time xybrix doesn't support attributes in elements at least, I've
not figured out how to do it ;)

I hope someone finds it useful, if for nothing else, a demonstration on how
xybrix might be used as a very lightweight GUI frontend for xweb.

thanks
Dennis

[Xweb-developers] GUI frontend using XML

[Dennis D. <dda...@ma...>]

Hello
I've had great success with building xml based forms using xybrix
(sourceforge). I'd recommend users of xweb take a look at it.
thanks
Dennis

Re: [Xweb-developers] Bean-flavoured XWeb 2.0 Proposal/Prototype

[Peter B. <pb...@me...>]

On Thu, 27 Dec 2001, Mikael St=E5ldal wrote:
> What is Doxygen?

Doxygen is a sourcecode documentaqtion generator which has some additiona=
l
features in comparison to the normal JavaDoc tool, e.g. inheritance and
collaboration diagrams and source code inclusion. Ask Google -- it should
be the first hit.

BTW: this is still writeen using a modem connection and Pine from a broke=
n
Win98 installation :-( Please excuse further delays.

  Peter

[Xweb-developers] Transmorpher

[Mikael S. <mik...@ho...>]

You might find the Transmorpher projects at 
http://transmorpher.inrialpes.fr/ interesting.

In their white paper, they make references to my master's thesis 
(http://www.staldal.nu/mikael/exjobb/) and the prototype XotW described 
therein, which is the basis for Lagoon.

Re: [Xweb-developers] Bean-flavoured XWeb 2.0 Proposal/Prototype

[Mikael S. <mik...@ho...>]

At 14:40 2001-11-25 -0500, Gord Pollock wrote:
>BTW, I was inspired to publish the Javadoc while reading/attempting to 
>understand the Lagoon API... I generated source doc for Lagoon using 
>Doxygen. I didn't use Doxygen for my stuff because it has effectively no 
>source code.

What is Doxygen?

BTW, the full documenation with Javadoc for Lagoon are now on the web 
(lagoon.sourceforge.net).

[Xweb-developers] XML Serialization

[Mikael S. <mik...@ho...>]

At 23:20 2001-11-22 -0500, Gord Pollock wrote:
>Note that XALAN IS REQUIRED, CAN'T USE SAXON. This is because it uses 
>Xalan's serialization API. (org.apache.xalan.serilize.*) (If there's a 
>generic serialization API in JAXP or elsewhere, someone please speak up...)

The JAXP 1.1 transformation API (javax.xml.transform.*) can be used for 
this by using an identity transform with a SAX or DOM Source and a Stream 
Result. I'm doing this in Lagoon, and it works fine with Xalan (I haven't 
tried SAXON or any other product).

Have a look at the nu.staldal.lagoon.producer.XMLFormatter class in Lagoon 
for a SAX serialization example.

Re: [Xweb-developers] Frontend Project (longish)

[Peter B. <pb...@me...>]

Werner Schuster wrote:
[...]
> I do have some other questions:
> - Is there some way to generate the Websites with relative URLs?
>   This might be useful for making "Websites" that will be stored locally
>   (or on a CD);
> - One thing I stumbled upon was, that it I can't easily copy files from the
>   input to the output; eg. I had 3 images in an article, and had to copy
>   each file with a seperate entry with type="copy"; is there an easier way?
>   If not, I am thinking of using Ant for this somehow (to sync input and
>   output dirs).

You are talking about the two most wanted features here. Unfortunately
both things can not be achieved easily in the current XWeb version,
there is no support for relative URLs (no, it is not that easy to
implement) and no support for wildcards (which don't fit into the
current structure). Both might change soon after I find more time for
XWeb again but at the moment you'll have to live with the problem, sorry
about that.

  Peter

Re: [Xweb-developers] Frontend Project (longish)

[Werner S. <wer...@ne...>]

On Monday 26 November 2001 07:23, you wrote:
> On the project management issue: creating a separate project seems
> reasonable -- I originally planned to add frontends into the project
> itself and maybe this will still happen but splitting the projects
> probably makes management easier, esp. if you really decide to support
> multiple backends. 

Well, the first big release (0.5, the release we have to present at 
University) won't have support for several backends; we are glad if we finish 
the few features we want to do; 

> I'll put a link on the XWeb website as soon as you have a website. 

OK; that won't be too soon, but I'll drop you a mail as soon as  we got 
something; We are planning to build the website using our tool, to have 
something to test it with as we go along. 

> I am willing to integrate your frontend into the XWeb
> CVS if you should feel like getting rid of the project later,

OK; lets see how everything turns out; 


I do have some other questions:
- Is there some way to generate the Websites with relative URLs? 
  This might be useful for making "Websites" that will be stored locally 
  (or on a CD); 
- One thing I stumbled upon was, that it I can't easily copy files from the 
  input to the output; eg. I had 3 images in an article, and had to copy 
  each file with a seperate entry with type="copy"; is there an easier way?
  If not, I am thinking of using Ant for this somehow (to sync input and 
  output dirs).


murphee

Re: [Xweb-developers] Bean-flavoured XWeb 2.0 Proposal/Prototype

[Peter B. <pb...@me...>]

Hello Gord,

I returned from my holidays today and I will need some time to catch up
with collected work. Detailed comments will follow later, here only a
proposal for the process:

why don't we put the source into the CVS and create the JavaDoc output
automatically (I can set up a cron job for this). Whenever someone feels
the need to change stuff he can do this (we can always roll back in CVS)
and we can add the reasoning into the logs. The advantages to the
current approach are:
- changes in the source files are connected to the reasoning (I am
talking about log entries that might be significantly larger than the
changes themself)
- we can use diffs to pick up changes
- the JavaDoc part is handled automatically

The only disadvantage I can see is that we split the discussions in some
way since I'd like to keep the more vague ideas on this list. But thanks
to the web frontends for the CVS and the ML archives we can create links
in both directions. And the CVS mailing list makes sure everyone can
stay up to date.

Of course this makes only sense once we have a basic structure fixed --
moving around files and renaming directories/files doesn't work well in
CVS.

Just some quick thoughts. And of course this implies that I think
documenting this part in form of interfaces (lowercase I) with good
JavaDoc comments is an appropriate way.

More hopefully soon,

  Peter



Gord Pollock wrote:
> 
> I was thinking of  writing up a description of what all the classes in
> the prototype do. Then I relized that the Javadoc was almost good enough.
> I expanded the Javadoc a bit, and published on :
> http://www3.sympatico.ca/gord.ca/
> Also, the source is on http://www3.sympatico.ca/gord.ca/src/ (Unchanged
> from what's in JAR in previous post, except for package space changes,
> and some additional Javadoc)
> 
> BTW, I was inspired to publish the Javadoc while reading/attempting to
> understand the Lagoon API... I generated source doc for Lagoon using
> Doxygen. I didn't use Doxygen for my stuff because it has effectively no
> source code.
> 
> _______________________________________________
> XWeb-Developers mailing list
> XWe...@li...
> https://lists.sourceforge.net/lists/listinfo/xweb-developers

Re: [Xweb-developers] Frontend Project (longish)

[Peter B. <pb...@me...>]

"Werner Schuster (by way of Werner Schuster )" wrote:
> 
> On Saturday 17 November 2001 13:57, you wrote:
> > At 04:55 2001-11-12 +0100, Werner Schuster wrote:
> > >Ant also makes it possible, to make updates of a website more comfortable,
> > >eg. it could be updated every day using a cron job, that simply calls Ant
> > >with target update (or something like that);
> >
> > I don't see what the need for Ant is in this case. Why can't you just
> > invoke XWeb in the cron job?
> 
> Yes, but when I say "update", I mean that I want to regenerate the Website
> (using XWeb) and *then* synchronize this with the Website on the server;
> 
> To do this, some synchronizing code has to be called to bring the Server
> up-to-date; this could be done using FTP, but also with other protocols/tools
> (WebDAV, CVS,...).
> The synchronization (obviously) has to happen after the website was built;
> I know, that you can call programms & java code from the XWeb def. file, but
> I am not sure, if that could be as flexible as using Ant;
> 
> Maybe I am underestimating the XWeb def. file here, but I just think that we
> could have a more elegant handling of the build & sync process, if Ant is
> used (if I am talking nonsense here, please correct me);

XWeb currently has no option to upload the resulting site in any
fashion. I always though about putting this into the frontend(s) but
using Ant as an additional intermediate layer seems a good idea.

Using Ant gives us reuse of the Ant tasks, offers far more flexibility
in combining different tools and different upload protocols and seems to
be an easy way to go. I always prefer the Unix-style approach of having
highly interoperable but small tools doing their job and Ant seems to be
an approach more suited at the moment than using bash or other shells
(not every Windows user installs Cygwin ;-) ).

Regarding the whole project (sorry I managed to lose some mails while
trying to access them on holidays and the web archive is nice to read
but not to answer mails): I think it is rather ambitious but sounds like
a reasonable approach. I am not sure if the more generic approach really
will offer the same usability as a highly specific applications but
compared to the cumbersome approach one has to take with plain XWeb it
will be a huge leap ahead.

On the project management issue: creating a separate project seems
reasonable -- I originally planned to add frontends into the project
itself and maybe this will still happen but splitting the projects
probably makes management easier, esp. if you really decide to support
multiple backends. I'll put a link on the XWeb website as soon as you
have a website. I am willing to integrate your frontend into the XWeb
CVS if you should feel like getting rid of the project later, as long as
you want to maintain the frontend I am happy to avoid the additional
work ;-)

I am really looking forward to your results.

  Peter

Re: [Xweb-developers] Bean-flavoured XWeb 2.0 Proposal/Prototype

[Gord P. <ghp...@un...>]

I was thinking of  writing up a description of what all the classes in 
the prototype do. Then I relized that the Javadoc was almost good enough.
I expanded the Javadoc a bit, and published on : 
http://www3.sympatico.ca/gord.ca/
Also, the source is on http://www3.sympatico.ca/gord.ca/src/ (Unchanged 
from what's in JAR in previous post, except for package space changes, 
and some additional Javadoc)

BTW, I was inspired to publish the Javadoc while reading/attempting to 
understand the Lagoon API... I generated source doc for Lagoon using 
Doxygen. I didn't use Doxygen for my stuff because it has effectively no 
source code.

[Xweb-developers] Bean-flavoured XWeb 2.0 Proposal/Prototype

[Gord P. <ghp...@un...>]

  I was going to compose an email desc'ing what a Xweb API with 
JavaBeans-like elements would look like. Then I decided to do one better 
and write up the attached sample.

This references the processing model doc heavily: 
http://meganesia.int.gu.edu.au/~pbecker/xweb/processingModel.html

It's 12 fairly small classes. To run, needs to be made with 
xerces.jar(1.x, I used 1.4.4), xalan.jar (v 2.x, used 2.2.D9), BCEL.jar, 
runtime.jar, java_cup.jar (all these included with Xalan). Note that 
XALAN IS REQUIRED, CAN'T USE SAXON. This is because it uses Xalan's 
serialization API. (org.apache.xalan.serilize.*) (If there's a generic 
serialization API in JAXP or elsewhere, someone please speak up...)

(BTW, this stuff was created in Forte for Java 3.0 Community Edition 
(ie, it's free) . I recommend it to everybody. XML and JavaBeans related 
components are way more advanced than those in the JBuilder free 
download version. Of  course if you actually have a copy of JBuilder 
Professional, it might be better... I don't have $ for such things.)

First, the example as it relates to the XWeb 2.0 Processing Model: (if a 
word is capitalized when it shouldn't be, it's referring to a class name 
in the sample). (This references the processing model doc heavily: 
http://meganesia.int.gu.edu.au/~pbecker/xweb/processingModel.html )

Streams - A stream consists of a documentBegin event, a bunch of events 
which contain the data constituting the stream, and a documentEnd event. 
If a processor wants to multiplex a stream, it just calls the output 
listener multiple times.
To set up a stream, you get a StreamListener from the receiving 
Processor with getInputListener. Then call addOutputListener with it on 
the Processor producing the events.

Data types - Currently, only SAX streams are supported. Then again, this 
is supposed to only be a demo. The different types are represented by 
subclasses of the StreamListener interface (ie, SAXListener, and 
possibly in future, DataListener). Type cheching consists of 
addObjectListener checking that the StreamListener it's given is an 
'instanceOf' the proper listner type (here SAXListener). Also a very 
possible future addition is DOMListener.
I'll insert a quick gripe here... While the model could easily support 
binary streams (where the events just hold Byte[]'s), I don't really see 
the need for them. Why can't a Processor that needs binary input just 
get it from a file and one that has binary output just put it in a file? 
When do you really have to do processing on binary data in this model?

Metadata, Context, Configuration & Parameters - There are currently two 
ways of providing such data to a Processor.
'Context' objects are passed to the Processor via the StreamListener 
object at the beginning of each stream(with the 
StreamListener.documentBegin event). In the sample they only provide the 
input filename and output filename. I suppose this really is what's 
called 'metadata' not 'context'. The 'final version' would include a 
reference to contextual data (input & output directories, navigation 
DOM, etc) in the Context object. Each Processor is responsible for 
passing its Context on to the Processor's that receive its output. This 
way the Processor could make some changes to the context. For example, a 
Processor that extracted SVG from XML documents would change the output 
filename for the SVG output steams. It could also add nodes to the 
navigation DOM that represent the images.

Configuration/parameter data is providing by adding JavaBean-like 
properties to the Processor. Parameters in JavaBeans consist of getter 
and setter methods. The JavaBeans spec allows for indexed properties (ie 
Array's), but not hashed properties (ie Dictionary's, indexed by 
String's or other Object's). So we'll have to break the spec or have 
'getXDictionary' methods...(ex XSLT parameters)

Processes - All processors are subclasses of Processor. As mentioned, 
they are configured via JavaBean properties and Context objects passed 
as the start of input and/or with the run() command.

One very bean-like feature I was thinking of incorporating into the 
prototype (but that would've involved actual programming...): Processors 
can define methods named getXInputStream returning a StreamListener. 
Then, when getInputStream() is called with String argument 'X', 
getXInputStream is called. Thus, the stream is named using a subset of 
the method name. Similarly, addXOutputListener would define an output 
stream named 'X'. Very much like what is done with JavaBeans' properties 
(their names are derived from the names of their getter/setter methods). 
If a processor wants to provide arbitrarily named streams, it can 
override the getInputStream(String)/addOutputListener(String) methods.

Macros - Implemented as a special type of Processor. Has sub-Processor's 
as its members (in an array, or list... or would we even need to store 
them as long as they're connected?) It defines arbitrary 
streams/properties that are mapped to member Processor's' 
streams/properties.

Usage/Syntax - Unchanged.

API - No need for a factory-like configuration. Just find and construct 
the requisite Processor classes. The name of a processor is the name of 
the class less suffix 'Processor'; the namespace is that of the class. 
If you want to use a processor not in the default namespace 
(net.sf.xweb.processors) you'll have to give the namespace every time 
you use the class or have some kind of 'import' declaration. (This could 
be changed...)

Configuration via hashtable/tree: My thinking is to have 'default' 
properties available regularly (like directly reading an 'inputFilename' 
property or setting 'indentAmount' property). Could throw in a hashtable 
for arbitrary parameters. Most Processor's wouldn't need arbitrary 
parameters though.

Introspection - Currently none, only gives error if try to access an 
invalid stream/property.  Could be changed.

Connecting processors - Use getInputStream on the receiving Processor, 
use to call addOutputStreamListener to sending processor. Has optional 
string arguments to specify which streams to use, or can just get the 
defaults.

Setting environment - The referenced 'central configuration' is set via 
properties; Things 'set for each run' are held/referenced in the Context 
object.

Problems
Output file URL's - I think the processors should be able to add nodes 
to the navigation DOM. This way, they could add files they are going to 
input. If a process is going to create a file other than its designated 
output file, it would add it to the nav DOM. Could also include a 
hashtable - that way we could handle name collisions on a 'first come 
first served' - the first processor to create a file named X gets to 
write that file. Files explicitly specified in the website sitemap would 
get highest priority.

Processes creating information others need (in general) - I dunno. Full 
dependancy definitions don't sound like much fun. Well, maybe they do to 
my geeky mind ;-), but they don't sound easily implementable/debuggable. 
My thinking is, if a processor needs info from another processor, it 
should be connected to it through streams. If a processor needs ouput 
from multiple processors, it sould cache received data until it's ready 
to produce its own. Mind you I'ven't thought about it much...

Error reporting - Definately need. Also, with control bouncing around so 
much, it'll be difficult to pinpoint the erronious processor. Not sure 
how though. I don't think we should think about multithreading yet. 
(Mind you I know near-zero about multithreading...)

Re: [Xweb-developers] Frontend Project (longish)

[Mikael S. <mik...@ho...>]

At 02:41 2001-11-19 +0100, Werner Schuster wrote:
>Yes, but when I say "update", I mean that I want to regenerate the Website
>(using XWeb) and *then* synchronize this with the Website on the server;
>
>To do this, some synchronizing code has to be called to bring the Server
>up-to-date; this could be done using FTP, but also with other protocols/tools
>(WebDAV, CVS,...).

I see. This makes sense given the current state of XWeb. I was thinking 
about Lagoon which have built-in uploading support.

>(I am not sure, but I guess that there is some Task that can handle CVS);

Yes, Ant have support for CVS.

Re: [Xweb-developers] Frontend Project (longish)

[Werner S. <wer...@ne...>]

On Saturday 17 November 2001 13:57, you wrote:
> At 04:55 2001-11-12 +0100, Werner Schuster wrote:
> >Ant also makes it possible, to make updates of a website more comfortable,
> >eg. it could be updated every day using a cron job, that simply calls Ant
> >with target update (or something like that);
>
> I don't see what the need for Ant is in this case. Why can't you just
> invoke XWeb in the cron job?

Yes, but when I say "update", I mean that I want to regenerate the Website
(using XWeb) and *then* synchronize this with the Website on the server;

To do this, some synchronizing code has to be called to bring the Server
up-to-date; this could be done using FTP, but also with other protocols/tools
(WebDAV, CVS,...).
The synchronization (obviously) has to happen after the website was built;
I know, that you can call programms & java code from the XWeb def. file, but
I am not sure, if that could be as flexible as using Ant;

Maybe I am underestimating the XWeb def. file here, but I just think that we
could have a more elegant handling of the build & sync process, if Ant is
used (if I am talking nonsense here, please correct me);

And: Ant already has Tasks that can use FTP to upload files, as well as
*many* other Tasks (Ant can be extended with Tasks for all kinds of things;
it comes with Tasks for eg. compiling,... but there is already a huge amount
of other Tasks available) for all kinds of things (I am not sure, but I guess
that there is some Task that can handle CVS);
That means, that we don't have to write that code ourselves (of course I
wouldnt write FTP handling code, but we would still have to find & integrate
some FTP code, while with Ant we simply have to add an FTP Task entry in the
build.xml to do it; PLUS many people use Ant, so it is likely that someone
writes Tasks for WebDAV,.. too);


I mentioned in my project description, that the GUI will have support for
PlugIns; these could also be used, to somehow generate (or fetch) data
(eg. from a database) and generate XML files, which will be put into the
Website file structure, and will then be transformed by XWEB into HTML (or
whatever) using XSLT; now, to update these XML files (eg. daily from a
database) you would have to call the PlugIn code before the generation of the
Website; thats where Ant comes in again;
You could simply add a call to some PlugIn class (that then updates the data)
to your Ant class (using our GUI) before the Website generation;
I am not sure, if something like that would be possible with the XWeb def.
file (maybe its possible, but I guess it wouldnt be as elegant as in Ant,
where you can specify tasks and also their dependencies);


Another big reason for using Ant was, that it wouldn't lock in the User with
our Programm (the FrontEnd); if the user doesn't like our GUI anymore, he
doesn't have to use it; If he can use Ant makefiles, he can continue working
with the files with no problem;
I also figured, that we would have to write some code to handle the build
process anyway, as soon as we offer more flexibility; The problem with this
is, that the build process would then be scattered inside Java code, for no
one (well, users anyway) to see and/or modify;
Many users would surely not care about that;
But the advanced user can make just about everything with the build process;
I mean, things that we just haven't thought about; We could of course make an
extensible build process system ourselves; but the advantage of using Ant is
now also, that the user can use a widely-used tool, and not something
specific for our Tool (and who would really spend time to learn some
AppSpecific Format or Language just to add some simply functionality?);

Well, I hope I made some sense in the paragraphs above;
If you think I talk utter nonsense and that I just don't understand anything,
please feel free to tell me; I am grateful for any feedback;

murphee

Re: [Xweb-developers] Frontend Project (longish)

[Mikael S. <mik...@ho...>]

At 04:55 2001-11-12 +0100, Werner Schuster wrote:
>Ant also makes it possible, to make updates of a website more comfortable,
>eg. it could be updated every day using a cron job, that simply calls Ant
>with target update (or something like that);

I don't see what the need for Ant is in this case. Why can't you just 
invoke XWeb in the cron job?

Re: [Xweb-developers] Frontend Project (longish)

[Mikael S. <mik...@ho...>]

At 04:55 2001-11-12 +0100, Werner Schuster wrote:
>When reading the XWeb Website (or was it the Lagoon website... sorry, 
>can't remember) I stumbled
>over some comment, where it was proposed to imagine the raw data before the
>Website generation as "source code", and the generated Website as "object 
>code";

That sounds familiar, it's on the Lagoon website.

[Xweb-developers] Frontend Project (longish)

[Werner S. <wer...@ne...>]

howdy,

remember me? The guy that wanted to write a Frontend for XWeb?
(Well, "wanted" is the wrong word, I should say "will").

I have spent some time thinking about what exactly we (me and my partner  for 
this project) should be writing. Starting with the proposal for a specific 
PhotoAlbum creator GUI, I thought what would be needed to really make this 
tool. A pure Photoalbum creation tool, might just not do everything you need, 
so we would have to add some generic GUI for manipulating the XWEB Definition 
file. Well, if you have that, what if someone just wants to use generic tool, 
and not the whole PhotoAlbum creator; well, to cut a long story short, this 
is what I plan on doing (first draft):

- Generic Interface
  + Xweb Tree manipulation bean (including a GUI widget)
  + configuration of the Website project (makefiles)
  + SyncManager (for synchronising locally generated Website with Server)
     possible supports pluggable modules for different kinds of sync'ing;
  + PlugIn Support 
- PlugIns
  + CollectionBuilder
     collects files in directories and stores links to them in a XML file;
     provides GUI for adding comments (&possible other data to each entry);
     this can be used for every kind of Files; might even get its data from
     Databases, and not just Filesytem;
   + PhotoAlbumBuilder 
     depends on CollectionBuilder; it adds a wizardish GUI for easy creation
     and maintenance of picture repositories; this PlugIn also comes with 
     several Templates, CSS files, Graphics & XSLTs  that users can use (but 
     might also support custom written ones).
     
Now, the idea is that you can start the GenericInterface on its own, and just 
handle the XWeb & Project stuff with a GUI, *and* also use the PlugIns;
The other way would be, that you can start the GenericInterface, with *one*
PlugIn "in charge"; this would mean, that eg. at the Start, you can see a 
SplashScreen supplied by the PlugIn, and the PlugIn can decide what to show 
in the GUI, but is free to use the GenericInterface controls; this would make 
it possible to have the functionality of the PlugIn in the GenericInterface, 
but to also allow the PlugIn to "act" as if it was a standalone application 
(without having to reinvent the wheels); 


So much for the GUI part;

As I said, I have given the whole thing some thought; When reading the XWeb 
Website (or was it the Lagoon website... sorry, can't remember) I stumbled 
over some comment, where it was proposed to imagine the raw data before the 
Website generation as "source code", and the generated Website as "object 
code";  From that, I realized, that the GenericFrontend would be like IDE
(to avoid confusion, I mean: Integrated Development Environement); 

which means, that it should help with building and deploying the project;
So I decided, to use Ant as an important part; the GenericFrontend would be 
building (and manipulating) Ant build files for the project;  the XWeb 
transformation would only be one part in the build process, like a call to a 
compiler; 
Maybe you're wondering, if using Ant isn't overkill, since the XWeb 
definition file is already a little like a makefile.
Ant is good because of several reasons; there are a lot of tasks already 
available, eg. uploading of files with FTP (which we could use in cooperation 
with the SyncManager).
Ant also makes it possible, to make updates of a website more comfortable, 
eg. it could be updated every day using a cron job, that simply calls Ant 
with target update (or something like that);
I guess you could do some tasks with the XWeb makefile stuff, but Ant is just 
much more powerful, AND it makes the GenericFrontend independant of the 
Website generation tool; ie you could use XWeb, Lagoon, ... in the background
(possibly even in the same website project, if you want), and are not tied to 
one (Although for our 1.0 release we're targeting XWeb, since our time is 
very limited);
Another good thing about using Ant makefiles for Website projects, is that 
the user is not locked into using our tool; if the user gets fed up with our 
tool, its possible to use just the makefile and Ant, without our tool;


Another thing about the organization of this project:
I thought about how this project should be organized; ie whether to be a part 
of XWeb or seperate; I finally decided for the latter, since I think that the 
XWeb project is only about the backend; If someone wants to use a GUI, 
he/she can simply get one GUI that uses XWeb, for example our project
(hmm, I still havent found a proper name). 

Well, I hope that we (the project group) can realise all (or at least a large 
subset) of the ideas listed in this mail until late January and thereby 
a) pass the lecture and b) provide a cool GUI for XWeb;

murphee

Re: [Xweb-developers] Re: XBeans

[Mikael S. <mik...@ho...>]

At 08:38 2001-11-05 +1000, Peter Becker wrote:
> >including communication of XML data via IIOP & friends, and, um, others...
>
>Although I don't see why you want to send pages of your website to a
>friend (or others) while compiling it

And if you want to, I would say that XML is an excellent format for the 
communication, probably over HTTP. I don't understand why you should use IIOP.

Re: [Xweb-developers] XWeb Frontend

[Mikael S. <mik...@ho...>]

At 08:30 2001-11-05 +1000, Peter Becker wrote:
>Then we need to specify things like:
>- name is one line text
>- birthdate is a date
>- department is one of ...
>- a remark is a multi-line text
>- there are multiple remarks allowed
>
>Part of this could probably be done with XML Schemas datatypes, but we
>still need some way to map this onto the screen (e.g. there are multiple
>ways to enter a date).

It seems like you should have a look at XForms, http://www.w3.org/TR/xforms/.

[Xweb-developers] Re: XBeans

[Peter B. <pb...@me...>]

Gord Pollock wrote:
> 
> Howdy all :)
> 
> First... Another project that I came across in my travels that has
> similarities... http://www.xbeans.org

Interesting ...
 
> XBeans are Java Beans that process XML, much like XWeb 2/Lagoon's
> processors. Other than that they're pretty different... XBeans are
> strung together by importing the beans into JBuilder (or similar), then
> connect them as event listeners in the properties dialog. Process
> properites also set in the bean's properties dialog. There's no
> mechanism to automatically connect beans through an XML 'style
> definition'. Also, streams aren't 'multiplexed' at all (though I suppose
> a bean could issue multiple documentReady events...) Uses DOM only, no
> SAX. The events are only 'documentReady' messages and include a
> reference to the DOM tree. Inefficient, yes.

I guess you got the most important drawback except one: they don't
support multiple inputs/outputs (needed for splitting XML islands out of
XHTML).

> One important feature is it uses the java.beans introspection methods,
> so it doesn't need any of its own. There was some talk (~5 sentences...)
> about using JavaBeans a long while back. You'dn't have to write much
> introspection code if you used beans...

I think we would have to, since we need some higher level introspection.
What we need is the ability of a processor to tell us how many
inputs/outputs it has, how it is called and so on. I don't think we
could handle all this easily with the standard introspection offered by
JavaBeans. On the other hand: I really don't know much about JavaBeans.

> In any case, writing a wrapper to use XBeans seems like good idea. It
> has some interesting beans, including communication of XML data via IIOP
> & friends, and, um, others...

Although I don't see why you want to send pages of your website to a
friend (or others) while compiling it I agree with the general idea:
having a wrapper for XBeans would be nice and should be easy to do since
they offer more or less a small subset of what we want to do. And maybe
the communication bean makes sense to transmit the final results
somewhere, you never know ;-)
 
  Peter

Re: [Xweb-developers] XWeb Frontend

[Peter B. <pb...@me...>]

Gord Pollock wrote:
> I wouldn't use parts of XUL in a servlet. That'd make it dependant on
> Mozilla (and a specific version of moz too...) Hate to admit it, but
> there are some other browsers out there that deserve consideration :)

The idea for the servlet is not to deliver XUL but to use some subset of
XUL as language for defining the interfaces created as pure HTML. If you
consider this XML:

  <person>
    <name>Jo Smith</name>
    <birthdate>11.03.63</birthdate>
    <department>Accounting</department>
    <remark>
      bla
      bla
      bla
    </remark>
    <remark>
      more      
      bla
      bla
      bla
    </remark>
  </person>

Then we need to specify things like:
- name is one line text
- birthdate is a date
- department is one of ...
- a remark is a multi-line text
- there are multiple remarks allowed

Part of this could probably be done with XML Schemas datatypes, but we
still need some way to map this onto the screen (e.g. there are multiple
ways to enter a date). This is where we might consider using some XUL
subset, but maybe we do our own stuff or look for other things, there
was something creating Java dialogs from XML made by alphaworks and Qt
uses XML for dialog layout, too. It's more about getting good ideas than
being compatible.

Regards,
  Peter

Re: [Xweb-developers] Processing Model for XWeb 2.0

[Gord P. <ghp...@un...>]

Howdy all :)

First... Another project that I came across in my travels that has 
similarities... http://www.xbeans.org

XBeans are Java Beans that process XML, much like XWeb 2/Lagoon's 
processors. Other than that they're pretty different... XBeans are 
strung together by importing the beans into JBuilder (or similar), then 
connect them as event listeners in the properties dialog. Process 
properites also set in the bean's properties dialog. There's no 
mechanism to automatically connect beans through an XML 'style 
definition'. Also, streams aren't 'multiplexed' at all (though I suppose 
a bean could issue multiple documentReady events...) Uses DOM only, no 
SAX. The events are only 'documentReady' messages and include a 
reference to the DOM tree. Inefficient, yes.

One important feature is it uses the java.beans introspection methods, 
so it doesn't need any of its own. There was some talk (~5 sentences...) 
about using JavaBeans a long while back. You'dn't have to write much 
introspection code if you used beans...

In any case, writing a wrapper to use XBeans seems like good idea. It 
has some interesting beans, including communication of XML data via IIOP 
& friends, and, um, others...

Comments:

Um... not much right now. It's kinda confusing, but thats to be expected 
from a first draft. The concept of processes should be put at the top, 
other ideas depend on it.

Gord.ca

Re: [Xweb-developers] XWeb Frontend

[Gord P. <ghp...@un...>]

Peter Becker wrote:

>>Another thought, was to somehow write some tools for Mozilla,
>>since I also use the Mozilla Composer; What I had in mind was
>>some XUL application; very simple, just to somehow add a HTML file
>>to an XWEB project, edit the structure, call upload code.
>>But since I have no clue about XUL programming yet, I doubt that
>>we will get that any time soon, especially since we are working
>>on a tight schedule.
>>
>There is a thread between Gord Pollock and me about this idea:
>
>  http://www.geocrawler.com/archives/3/12269/2001/6/0/6010513/
>
>I never really looked into this myself, I think Gord gave up on going
>this way. One idea that I currently have is to use some subset of XUL in
>the servlet for defining interfaces for specific XML formats.
>
Yeah, that idea's pretty much dead. Mikael asked ~6 wks ago if there 
were any advantages to XUL over Swing. Answer (finally) : not really.

It's major problem is lack of maturity. There are zero tools to help you 
write XUL, as compared to too many tools for java. Also, XUL definition 
tends to change every couple releases. An XUL app targeting Moz 0.8 
prolly wont work with 0.9.5 and def'ly wont work with 1.0. All code is 
javascript, hard to debug. I hear that 0.9.5 (latest) finally has a JS 
debugger, havn't looked at it though. And so on...

Theoretical advantages: easy integration with XML (turns out it uses RDF 
mostly, which XWeb doesn't use), easy to make interfaces. Didn't turn out.

Admittedly, main problem is lazyness :) And main reason for starting XUL 
frontend was to learn XUL.

I wouldn't use parts of XUL in a servlet. That'd make it dependant on 
Mozilla (and a specific version of moz too...) Hate to admit it, but 
there are some other browsers out there that deserve consideration :)

Re: [Xweb-developers] Processing Model for XWeb 2.0

[Mikael S. <mik...@ho...>]

At 08:58 2001-10-29 +1000, Peter Becker wrote:
>I never figured out how to do this. I still use Class.forName(..) to
>load my classes -- what do I miss? And wouldn't it be rather expensive
>to load every class in the classpath?

You don't load all classes in the CLASSPATH. In Lagoon you do this by 
placing a small property file in the CLASSPATH in a predefined package, 
which contains the name of the implementation class.

In Lagoon, if you want to provide a transform producer of the type "foo", 
you implement your class com.foo.FooTransform and then put a file 
"/nu/staldal/lagoon/producer/transform-foo" containg the classname 
com.foo.FooTransform in the CLASSPATH. If you refer to a transform producer 
of the type "foo", Lagoon will lookup this property file (using 
Class.getResourceAsInputStream()) and find the implementation class there.

>Alternatively we could use the XWEBHOME variable to check a subdirectory
>(e.g. "plugins") there and load every class file we can find there (that 
>should be easy).

That doesn't sound like a good idea.

> > * Try to avoid using multithreading as much as possible, it will 
> complicate things.
>
>Why? As long as we have a pure push model we can't get dead- or
>livelocks. The processing model should constitute an acyclic graph and I
>don't see any need for synchronization either -- except for processes
>with multiple inputs where it should be easy to handle. But we can
>postpone this until we get something running, I just would like to make
>sure in the design that we have the option to go there.

I mean that we shouldn't rely on multithreading.

Re: [Xweb-developers] Processing Model for XWeb 2.0

[Peter B. <pb...@me...>]

"Mikael St=E5ldal" wrote:
>=20
> At 12:36 2001-10-27 +1000, Peter Becker wrote:
> >Comments are not only very welcome but the main purpose of this docume=
nt ;-)
>=20
> OK, here are some comments.
>=20
> * Exactly what does multiplexing mean?

Combining multiple streams of the same type into one. E.g. if you have a
process that splits XHTML with SVG and MathML islands into the subparts
you will get only three streams: XHTML without islands, SVG and MathML
but the latter can be multiplexed, i.e. they can contain multiple
instances which all should be processed in the same manner. I think we
need this since we can't tell how many SVG or MathML islands we will
get.
=20
> * What is the difference between configuration and parameters?

The configuration is what defines the process -- it will be something
similar to the current <documentStyle>s. The parameters are something
new: they would be possible on each document, refining the process
settings. For example: for our group website we used one big BibTeXML
file to store all publications, but the pages created are grouped by
year ([1]). To create e.g. the page for 2000 we call a stylesheet with
the parameter "year" set to "2000". This is currently done by creating
different processes for each year, which doesn't seem right. What I'd
like to do is to define a process that can get additional paramters as
children of the <entry>s.

> * By "makefile", you mean the web site definition file XWeb uses? (It's
> called "sitemap" in Lagoon.)

Yes.

> * It should be possible to plugin a new processor by just add a JAR fil=
e to
> the CLASSPATH. You shouldn't have to change any central configuration, =
or
> to include a definition in the makefile, unless you want to alter the
> factory default configuration.

I never figured out how to do this. I still use Class.forName(..) to
load my classes -- what do I miss? And wouldn't it be rather expensive
to load every class in the classpath?

Alternatively we could use the XWEBHOME variable to check a subdirectory
(e.g. "plugins") there and load every class file we can find there (that
should be easy).
=20
> * Try to avoid using multithreading as much as possible, it will compli=
cate
> things.

Why? As long as we have a pure push model we can't get dead- or
livelocks. The processing model should constitute an acyclic graph and I
don't see any need for synchronization either -- except for processes
with multiple inputs where it should be easy to handle. But we can
postpone this until we get something running, I just would like to make
sure in the design that we have the option to go there.

  Peter


[1] http://meganesia.int.gu.edu.au/~pbecker/kvo