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

[Xweb-developers] Re:Changes to XWeb

[Hendrik L. <hen...@gm...>]

Wednesday, November 5, 2003, 9:46:56 PM, you wrote:

> The main thing I'd like to get rid of is Xerces since it is so huge. Do
> you know how close the ORO API is to the JDK 1.4 RegEx approach?

Just looking into it:
It seems to support the full set of POSIX RegEx (the type of RegEx
supported is not stated, so I assume POSIX). But it does not support
substitution, so this must be done manually (grouping is supported,
though). I still would prefer ORO: it is the most complete lib out there,
its small, and fairly stable.

>>>- something for logging like log4j
> It is not just about size, it is also about being mainstream. But of

Log4j is the most mainstream you can get for logging. Its small, fast,
stable, and pretty configurable (I always use the notion of 2 log targets=
:
one for the application [structured by the application components], one f=
or
debugging [structured by the Java classes]. Its really simple to do). It
got a lot of tools (just have alook at the supported Appenders...).And it
supports Java since 1.2, too. Commons Logging and the util.logging from 1=
.4
are just inferior.

> ImageIO is part of the JDK -- I use it in some other programs to export
> PNGs and JPGs. No extra libraries needed. And the API is a lot nicer=20
> than JIMI or JAI (the latter being incredibly bad in design).

I seem to have confused this with the JAI Image I/O (from
http://developer.java.sun.com/developer/earlyAccess/jai_imageio/), which =
is
what I use (additionally to the Java Imaging Utulities)

>>You are really optimistic :) My first test case would be something like
>>source=3D'??some*.?htm?' target=3D'$1next$2.html'
> You could always map it to something like "..some.*\..htm." and run the
> RegExp machinery.

Thats what ORO is doing internally for glob expressions. The problem ther=
e
is that for substitution with RegEx, one has to use () expressions in the
matcher RegEx to generate the groups used for substitution. And as they a=
re
regular chars in a glob expression, one cannot specifiy them for the
substitution... Possible solution: find all '.' and '*' expressions in th=
e
glob expression, and suround them with () in the generated RegEx.

> I find the glob format a lot easier for simple things

ACK

> like matching file names and I think there are many people who use XWeb=
=20
> but don't know much about RegExp. Forgetting to escape the dot would be=
=20
> a first problem.

> [adding the file name also as id]

[Discussing the ID generation when copying multipel files at once]
> I am a bit afraid of namespace pollution. If you just use a file name a=
s=20
> ID, there are lots of IDs generated. And if you want to use the file=20
> name anyway, you can just put it into a URL. The internal linking=20

I wanted the ID to make sure the link is correct (I will get a warning if
it is not because of a typo). Maybe a link checker for internal link woul=
d
solve this?

> Another option would be doing both with optional ID generation, possibl=
y
> with an id pattern attribute on the <entryset>. This could look like th=
is:
>   <fileset sourceFiles=3D"*.xml" targetFiles=3D"$1.pdf" type=3D"docbook=
PDF"
> ids=3D"pdf_$1"/>
> The @ids would be optional and no ids would be generated if it is missi=
ng.

Thats what I was thinking anyway...

hli
--=20
M=F8=F8se trained to mix concrete and                                 Hen=
drik Lipka
sign complicated insurance forms                           hendrik.lipka@=
gmx.de
                                                            www.hendrikli=
pka.de

[Xweb-developers] Anyone problems with JDK 1.4?

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

Hi all,

I want to move on to JDK 1.4 unless someone thinks this causes serious 
problems. At least I'd like to release the next unstable release (1.1.M1 
or however it will be called) based on JDK 1.4 and then see the user 
reactions. Things I'd like to use from 1.4 are:

- JAXP (i.e. dropping the Xerces.jar)
- Logging
- RegExp
- ImageIO (i.e. dropping JIMI)
- nested exceptions
- possibly nio

Of course all these things can be achieved with extra libraries, but:

- I am quite used to the 1.4 JDK by now
- I don't want to run a separate test environment for pre-1.4 (all my 
JDKs/JREs have been updated by now)
- the download size would decrease big time (just xercces.jar makes up 
1.8MB out of 3.3MB)

Any comments? Someone expecting problems?

  Peter

[Xweb-developers] Reactivating development

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

Hi all,

with some nice little example of synchronicity two things happened 
yesterday: (1) a friend of mine (Jon) and I decided to do some work on 
XWeb and (2) someone (Hendrik) mailed a bunch of patches.

I moved the discussion about (2) onto the list (as you noticed). Here 
are some updates about the rest of the development:

1.0: a few weeks ago Thomas DeWeese (of Batik fame) and I worked out how 
to fix the problem that stopped me from calling XWeb 1.0 a final. It is 
related to the gAMA chunks in PNG, the problems with that are described 
here: http://www.hut.fi/u/hsivonen/png-gamma.html. The CVS Batik of 
Batik works for me now, at the moment I am still waiting for a new 
release, if that doesn't happen I might just do a build from CVS.

1.1: my plans are adding some of the most requested features. There have 
been some changes in the trunk for a while, most noticably an 
<imageCopy> option, which can be used to rescale images. 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
- 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.
- a large refactoring towards a process-oriented model with at least two 
iterations through the chains (prepare, do)
- more sophisticated distributions, I'd like to see some installer (many 
users stumble on the environment setup bit) and maybe using jstub 
instead of batch/script files (http://www.roxes.com/produkte/rat.html)

Jon wants to have a go at the frontend bit, at least some tree 
manipulations with a text editor pane, maybe integration of something 
like ekit (http://www.hexidec.com/ekit.php) or dreaming#7 
(http://dreaming.sourceforge.net/) as HTML editors. Shell-execute on 
Windows is easy, too -- to open files in their default application. So 
far I haven't seen any really good way to do this on UNIX systems, the 
best thing I know is this: http://browserlauncher.sourceforge.net/. If 
someone knows something better, please shout.

Hopefully you'll see quite a few changes happening soon. It's a good 
time to request features, too :-)

  Peter

[Xweb-developers] Re: Changes to XWeb

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

[moved to the dev list -- for those tuning in: Hendrik submitted a few 
patches and I plan to do some changes to XWeb together with Jon 
(mentioned below). I tried to add some hints about the preceeding 
discussions, it was only two mails back and forth]

Hendrik Lipka wrote:

>Wednesday, November 5, 2003, 2:51:30 PM, you wrote:
>
>  
>
>>I have thought about making big architectural changes for a long time by
>>now, up to a complex processing model with streams, meta-data, 
>>multi-plexing and others. But a first step would be getting closer to 
>>the model of Lagoon or Transmorpher with simple one input, one output 
>>processors in a queue and implicit SAX- to ASCII-stream conversions.
>>    
>>
>
>Personally, I'm happy with the current model. Its easy to unterstand, and
>fulfills most needs, I think.
>  
>
It is limiting, e.g. you can't do things like first XSLT, then SVG 
transformation. Same for FOP. And you can't combine the power of UNIX 
tools into the process by running stuff like sed or scripting languages 
at some stages. Freemarker would be another thing I'd like to support 
(http://freemarker.sourceforge.net/).

To do this properly, XWeb needs a general notion of a toolchain, not 
just for XSLT.

>>Some pointers:
>>- http://transmorpher.inrialpes.fr/docs/compare.html
>>- http://meganesia.int.gu.edu.au/~pbecker/xweb/processingModel.html
>>    
>>
>
>Interesting read.
>
>  
>
>>But it would probably be handy for people who want to manage the whole
>>process around this with Ant -- like the ftp or http uploads, maybe
>>    
>>
>
>Sound like me :)
>
>  
>
>>My suspicion is that you will end up rendering again quite often. But at
>>least in the situation of a typo-fix and similar local changes it should 
>>be ok. We would need a way to define extra dependencies, though -- at 
>>    
>>
>
>Something like a <depenson> element below the entries should do. When a
>style changes, everything is rebuild, otherwiese the dependencies are used.
>  
>
Yes, that was what I was thinking of.

>>Libraries needed in 1.3, which are part of 1.4:
>>- RegExp library like ORO
>>    
>>
>
>I think ORO is the most complete RegEx library around, and its only 65k.
>  
>
The main thing I'd like to get rid of is Xerces since it is so huge. Do 
you know how close the ORO API is to the JDK 1.4 RegEx approach?

>>- something for logging like log4j
>>    
>>
>
>Log4J ist also one of the most complete loggers, and not _that_ large.
>  
>
It is not just about size, it is also about being mainstream. But of 
course Jakarta is reasonably mainstream and there are other things I 
might want to use from them, e.g. the CLI or FileUpload stuff from 
Commons. The Commons Logging package might be a good idea, too -- esp. 
in the case we want to go a mixed 1.3/1.4 route.

>>- something for image output like JIMI (another bigger lib in the 
>>current XWeb)
>>    
>>
>
>JDK1.4 has some image processing classes, but the ImageIO lib is still
>required :(
>  
>
ImageIO is part of the JDK -- I use it in some other programs to export 
PNGs and JPGs. No extra libraries needed. And the API is a lot nicer 
than JIMI or JAI (the latter being incredibly bad in design).

[discussing the idea of an <entryset>, which uses regular expressions or 
globbing and gets expanded to a number of <entry>s]

>>globbing bit might require writing some matcher of our own, but that is
>>easy, too.
>>    
>>
>
>You are really optimistic :) My first test case would be something like
>source='??some*.?htm?' target='$1next$2.html'
>Renaming just the extensions would be easier...
>  
>
You could always map it to something like "..some.*\..htm." and run the 
RegExp machinery. I find the glob format a lot easier for simple things 
like matching file names and I think there are many people who use XWeb 
but don't know much about RegExp. Forgetting to escape the dot would be 
a first problem.

[adding the file name also as id]

>>>My website has a list of downloads, and with such generated IDs I could
>>>make sure all links are indeed correct.
>>>      
>>>
>>Couldn't you just id the section (or better directory) and do a match on
>>"\\directory[id='downloads']\file"?
>>    
>>
>
>I wanted to generate the links just by giving the ID.
>  
>
I am a bit afraid of namespace pollution. If you just use a file name as 
ID, there are lots of IDs generated. And if you want to use the file 
name anyway, you can just put it into a URL. The internal linking 
feature of the generic stylesheet could be extended to evaluate 
something like href="!downloads/myFile.pdf". Admittably a bit more 
typing than just "!myFile.pdf", but as I said: the other option is a 
huge collection of IDs around.

Another option would be doing both with optional ID generation, possibly 
with an id pattern attribute on the <entryset>. This could look like this:

  <fileset sourceFiles="*.xml" targetFiles="$1.pdf" type="docbookPDF" 
ids="pdf_$1"/>

The @ids would be optional and no ids would be generated if it is missing.

>>Ok -- I don't think Jon is subscribed yet. Jon: can you make sure you
>>are on the list so we can all take it there? I suspect some of the old 
>>    
>>
>
>He was not on CC...
>  
>
My sentbox claims so. He should get this and we'll meet tomorrow anyway.

>>I'll go through the changes and might commit some to the trunk. After
>>that I'll post some update on the list.
>>    
>>
>
>I stay tuned.
>  
>
Back soon.

  Peter

Re: [Xweb-developers] id attribute for <file>s?

[J. H. <jh...@us...>]

On Wed, Oct 30, 2002 at 04:43:19PM +1000, Peter Becker wrote:
> Hi Jo,
> 
> the stylesheet did search only for <entry>s, I changed it to pick up 
> <file>s and <section>s, too. Check out the latest CVS version:
> 
>   
>  http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xweb/dist/stylesheets/generic.xsl?rev=1.2&content-type=text/vnd.viewcvs-markup
> 
> and give me feedback if it works for you -- I am still busy with loads 
> of other stuff and don't even have an XWeb setup at the moment to test 
> it myself. Hopefully I'll have a bit of time to fix some stuff soon. But 
> I said that before, didn't I?
> 
>   Peter

Yes, it does work. However, how about simply putting

<xsl:when test="//entry[@id=$id]|//file[@id=$id]">
   <a href="{//entry[@id=$id]/@src|//file[@id=$id]/@src}" class="xwebLink">
  ...

instead of two sections? IMHO it makes the idea more clear.

Then I propose to update also the generic.xsl's in

./manual/layout/generic.xsl
./examples/kvoWebsite/layout/generic.xsl


Just tell me when I should make the change. I do not dare to mix into
real developers stuff right now, but if you allow me to I will do so ;-)

Cheers,

Jo

PS: I read in the online forums about some gallery making stuff and code
enhancements. Is this already in CVS?


-- 
J. Hereth <he...@ma...>
Darmstadt University of Technology, Department of Mathematics

Re: [Xweb-developers] id attribute for <file>s?

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

Hi Jo,

the stylesheet did search only for <entry>s, I changed it to pick up 
<file>s and <section>s, too. Check out the latest CVS version:

  
 http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xweb/dist/stylesheets/generic.xsl?rev=1.2&content-type=text/vnd.viewcvs-markup

and give me feedback if it works for you -- I am still busy with loads 
of other stuff and don't even have an XWeb setup at the moment to test 
it myself. Hopefully I'll have a bit of time to fix some stuff soon. But 
I said that before, didn't I?

  Peter



J. Hereth wrote:

>Hi,
>
>I was trying to use the xweb link feature for files (using
>generix.xsl):
>
>In the xweb-file an entry of the form
>
><file sourceFile="file" targetFile="file" type="copy" id="something"/>
>
>Then, in one of the source files
>
><a href="!something">File</a>
>
>However, xweb complains:
>
>Could not find id 'something' on any entry page
>
>Sure, it's a file, not an entry.
>
>Is this a bug or a feature?
>
>Cheers,
>
>Jo
>
>  
>

[Xweb-developers] id attribute for <file>s?

[J. H. <jh...@us...>]

Hi,

I was trying to use the xweb link feature for files (using
generix.xsl):

In the xweb-file an entry of the form

<file sourceFile="file" targetFile="file" type="copy" id="something"/>

Then, in one of the source files

<a href="!something">File</a>

However, xweb complains:

Could not find id 'something' on any entry page

Sure, it's a file, not an entry.

Is this a bug or a feature?

Cheers,

Jo

-- 
J. Hereth <he...@ma...>
Darmstadt University of Technology, Department of Mathematics

Re: [Xweb-developers] Invoking XWeb twice

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

murphee wrote:

> Michael Weers wrote:
>
>> Hello!
>> I'd like to know if the problem of invoking Xweb twice within the same
>> running JVM has been solved. I don't think so, having tried a late 
>> CVS version, too. If not, where in the source code should one start 
>> to fix  that problem?
>
>
>
> Well, the source code that you included in your post should be the 
> place to go.
>
> >             if( itLayout.hasNext() )
> >             {
> >                 // clean up types (otherwise we get duplicates)
> >                 DocType.clearTypes();
> >                 SectionType.clearTypes();
> >                 // remove all <img> elements in navigation structure
> >                 removeImageElements( 
> _DOM.getRootElement().getChild() );
> >                 System.gc();
> >             }
>
>
> If you could somehow get this if-block to be executed, then everything 
> should work.
> Hm... come to think about it, you could completely remove the 
> if-clause at the
> beginning thus executing the code each time processWebsite is called. 
> I guess, it
> can't do too much harm.
>
> Mind you, this is not my code, so what I just wrote, might be really 
> be nonsense, but
> I guess it's worth a try. 

That should work. I really should stop doing semi-global variables.

If you run this code all the time you will loose a little bit of 
performance, but otherwise it should be ok. And I do not think the 
performance hit will be noticeable.

   Peter

Re: [Xweb-developers] Invoking XWeb twice

[murphee <wer...@ne...>]

Michael Weers wrote:
> Hello!
> I'd like to know if the problem of invoking Xweb twice within the same
> running JVM has been solved. I don't think so, having tried a late CVS 
> version, too. If not, where in the source code should one start to fix  that problem?


Well, the source code that you included in your post should be the place 
to go.

 >             if( itLayout.hasNext() )
 >             {
 >                 // clean up types (otherwise we get duplicates)
 >                 DocType.clearTypes();
 >                 SectionType.clearTypes();
 >                 // remove all <img> elements in navigation structure
 >                 removeImageElements( _DOM.getRootElement().getChild() );
 >                 System.gc();
 >             }


If you could somehow get this if-block to be executed, then everything 
should work.
Hm... come to think about it, you could completely remove the if-clause 
at the
beginning thus executing the code each time processWebsite is called. I 
guess, it
can't do too much harm.

Mind you, this is not my code, so what I just wrote, might be really be 
nonsense, but
I guess it's worth a try.

murphee

[Xweb-developers] Invoking XWeb twice

[Michael W. <Mic...@gm...>]

Hello!

I'd like to know if the problem of invoking Xweb twice within the same
running JVM has been solved. I don't think so, having tried a late CVS 
version, too. If not, where in the source code should one start to fix 
that problem?

Obviously the problem here is the static Hashtable attribute in one (or 
even multiple ?) classes. I noticed it in the
...backend.images.ImageGenerator
class. But I didn't find a proper place to clear these collections after 
XWeb completed a website build.

I am currently writing a very small graphical Java application that lets 
  the user select a Website file to build the site.

Thanks in advance,
Michael


Below cited from a posting earlier this year:

  > There is nothing I'd call a proper solution but changing the source
  > should be rather easy since this problem did occur before: if XWeb
  > generates multiple layouts from one website file, the layout definitions
  > have to be cleared, too.
  >
  > Here is the code fragment responsible for this, found in
  > WebsiteProcessor.java at line 144ff. :
  >
  >             // clean up if there is another layout
  >             if( itLayout.hasNext() )
  >             {
  >                 // clean up types (otherwise we get duplicates)
  >                 DocType.clearTypes();
  >                 SectionType.clearTypes();
  >                 // remove all <img> elements in navigation structure
  >                 removeImageElements( _DOM.getRootElement().getChild(
  > "structure" ) );
  >                 // call GC -- otherwise the new types will be removed
later
  >                 System.gc();
  >             }
  >
  > That's obviously not a nice way to solve the issue, but maybe it helps
  > with your problem, too. The way XWeb is called from the CLI is pretty
  > much specialized for this approach, that's one of the many things I'd
  > like to refactor.
  >
  >

Re: [Xweb-developers] zip-files

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

Jesper Zedlitz wrote:

 >-----BEGIN PGP SIGNED MESSAGE-----
 >Hash: SHA1
 >
 >Wouldn't it be nice to use xml-files that are inside a zip-file?
 >That would make it possible to access the content of an OpenOffice 
document
 >directly without unzipping the file each time after a change.
 >An idea how that would look in the website.xweb:
 ><entry name="test" zipFile="files.zip" zipEntry="content.xml"
 >targetFile="test.html" type="openoffice-text" />
 >Other possibility would be to use the normal "sourceFile" attribute 
instead
 >of "zipFile".
 >What do you think about that idea?
 >
Although I started using this document-oriented scheme myself, I'd by
now prefer a more process-oriented approach, which would mean in this
case that unzipping is part of the process defined in the
<documentStyle>, not of the entry. This is probably the same Murphee 
proposed in his comment. The idea would be to create a process
a zipped XML file with something like this:

<unzip extractFile="content.xml/>
<parseXML [maybe some option for validation etc.]/>
<xslt stylesheet="number1.xslt">
     <parameter name="myParam" value="7"/>
</xslt>
<addNavigation parentElement="html"/>
<xslt stylesheet="layout.xslt"/>

This would create a stream starting binary, switching to XML in the
second step and being serialized implicitely at the end. I think this
approach is more flexible and actually it might be a bit simpler in the
long run since one has  no need to remember which things belong on the
<entry>s and which in the process definition.

Unfortunately XWeb is a bit away from this  -- maybe the jar: URL scheme
offers some workaround. Another would be adding an <unzip> element 
around the <xslt> elements, which would probably be easy to add though 
the code would be yet another hack.

    Peter

Re: [Xweb-developers] zip-files

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

At 16:42 2002-04-12 +0200, Jesper Zedlitz wrote:
>Wouldn't it be nice to use xml-files that are inside a zip-file?
>That would make it possible to access the content of an OpenOffice document
>directly without unzipping the file each time after a change.

That should be possible by using an URL with jar: scheme. See the javadoc 
on java.net.JarURLConnection. It works with normal zip files as well as jar 
files.

I haven't tried it with XWeb, but it works with Lagoon.

Re: [Xweb-developers] zip-files

[murphee <wer...@ne...>]

Jesper Zedlitz wrote:

 >That would make it possible to access the content of an OpenOffice 
document
 >directly without unzipping the file each time after a change.
 >An idea how that would look in the website.xweb:
 ><entry name="test" zipFile="files.zip" zipEntry="content.xml"
 >targetFile="test.html" type="openoffice-text" />
 >Other possibility would be to use the normal "sourceFile" attribute 
instead
 >of "zipFile".
 >What do you think about that idea?
 >

hm... just of the top of my head, how about you define a special doc
Style for OpenOffice documents, that tries to unzip them before handling
them;
In a documentStyle you can define a series of action that you can apply to
a document (XSLT, SVG, programCall). I guess you could make the
documentStyle execute an unzip before doing anything else with the 
document. (Sorry, I
don't have any XWEB documentation here, so I cant offer a sample; nor am 
I sure,
whether there aren't any problems with this approach (one thing comes to 
mind: the
name of the file would have to be xyz.zip, but when you unzip it, it 
would be
xyz.xml; so the next steps in the documentStyle would process the .zip 
file, not the
.xml file; Or am I misunderstanding something here? )).


another solution might be, to use an external build program, to build an
XWEB website;
ie. something like make, or even better: Ant. By doing so, you could
define rules, that could walk your directory tree (*before* building it 
with XWEB), and
unzip every file that it finds along the way.

(dirty little selfpromotion: I tried that (not for zip, but generally)
with my webbuilder project, which is supposed to be sort of a
  frontend for XWEB, using Ant for the  build process.
In case anyone is interested, a version of it  can be obtained at
http://www.angelfire.com/co/werners/webbuilder/
(be sure to check out the presentation slides for internals).
Caution: This is a far from a complete (and working) version of the
program, but I guess one can see where it's aimed at.).


murphee

[Xweb-developers] zip-files

[Jesper Z. <je...@ze...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wouldn't it be nice to use xml-files that are inside a zip-file? 
That would make it possible to access the content of an OpenOffice document 
directly without unzipping the file each time after a change.
An idea how that would look in the website.xweb:
<entry name="test" zipFile="files.zip" zipEntry="content.xml"
targetFile="test.html" type="openoffice-text" />
Other possibility would be to use the normal "sourceFile" attribute instead 
of "zipFile".
What do you think about that idea?

Jesper

- -- 
+----------------------------------------------------------+
 Jesper Zedlitz   eMail    : je...@ze...      
                  Homepage : http://www.zedlitz.de  
                  ICQ#     : 23890711               
                  PGP-Key  : http://zedlitz.de/pub_key.asc
+----------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8tvJDjSxW58yLxdgRAuIUAJ9/BegRl87Cijq8jLSU09cC1LeTOgCgkTDx
1em0nNe7fFFS0ZDtUd6eFbo=
=uu4d
-----END PGP SIGNATURE-----

[Xweb-developers] Solved!

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

Ok, it took a while but I tracked it down to 
org.w3c.dom.Document.importNode(..) in the Xerces version I used in 
XWeb. It works with the 1.4.4 version, which I will include in the new 
XWeb release. Do you reckon Xerces 1 is stable enough to do a final 
anyway? XWeb itself got only a minor change in the error handling for 
missing "type" attributes.

  Peter


Peter Becker wrote:

> Hello,
>
> I am currently trying to debug some problem I encountered last weekend 
> when testing the planned 1.0 release: XWeb doesn't work with JDK 1.4, 
> neither on Windows nor on Linux.
>
> The problem is that all attributes added by XWeb into the DOM for the 
> XSLT process end up empty. The results look like this:
>
>  <file active="" sourceFile="" src="" targetFile="" type=""/>
>
> Note that the copying of the element and the attributes worked and 
> that the additional attribute "active" was added, but without any 
> value. This means either commands like
>
>  activeElement.addAttribute( "active", "true" );
>
> work only partly (tested with JDOM b6 and b7) or the DOM is changed 
> appropriately but not outputted in the way it should. I'll try to get 
> some intermediate debug output directly from the DOM and I'll switch 
> to a different transformer, but maybe someone of you knows something 
> about the problem. Any hints are welcome.
>
> Thanks,
>   Peter
>
>
>
> _______________________________________________
> XWeb-Developers mailing list
> XWe...@li...
> https://lists.sourceforge.net/lists/listinfo/xweb-developers
>

[Xweb-developers] JDK 1.4 issues

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

Hello,

I am currently trying to debug some problem I encountered last weekend 
when testing the planned 1.0 release: XWeb doesn't work with JDK 1.4, 
neither on Windows nor on Linux.

The problem is that all attributes added by XWeb into the DOM for the 
XSLT process end up empty. The results look like this:

  <file active="" sourceFile="" src="" targetFile="" type=""/>

Note that the copying of the element and the attributes worked and that 
the additional attribute "active" was added, but without any value. This 
means either commands like

  activeElement.addAttribute( "active", "true" );

work only partly (tested with JDOM b6 and b7) or the DOM is changed 
appropriately but not outputted in the way it should. I'll try to get 
some intermediate debug output directly from the DOM and I'll switch to 
a different transformer, but maybe someone of you knows something about 
the problem. Any hints are welcome.

Thanks,
   Peter

Re: [Xweb-developers] Comments about XWeb

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

murphee wrote:

> Peter Becker wrote:
>
> >> change the XWeb source. Is there a proper solution for this, or would
> >> this require some change
> >> in the XWeb source?
> >
> > There is nothing I'd call a proper solution but changing the source
> > should be rather easy since this problem did occur before: if XWeb
> > generates multiple layouts from one website file, the layout
> > definitions have to be cleared, too.
>
> > Here is the code fragment responsible for this, found in
> > WebsiteProcessor.java at line 144ff. :
> >
> >            // clean up if there is another layout
> >            if( itLayout.hasNext() )
> >            {
>
>  ... code snipped...
>
> > That's obviously not a nice way to solve the issue, but maybe it helps
> > with your problem, too. The way XWeb is called from the CLI is pretty
> > much specialized for this approach, that's one of the many things I'd
> > like to refactor.
>
> hmm... I guess it might work, if I put a second *empty* Layout
> Definition in the .xweb file, ... that would "flush"
> the previously used Layout (and the styles,... defined in it); 

That's a really nasty hack! If you call XWeb directly you should be able 
to do everything you need by calling the methods. But maybe the most 
simple solution would be removing the if and cleaning up after every 
layout -- it shouldn't really hurt to explicitely clean up after the 
last run.

[...]

> > 2) if you want to create multiple outputs from one XML file with only
> > one navigation entry you could use a combination of one <entry> and
> > multiple <file>s. I think this is conceptually ok (you have one entry
> > in the navigation, pointing to the first page and the others are just
> > files), the missing feature here is the ability to attach XSLT
> > parameters to the entries. At the moment you will have to create one
> > <documentType> for each page just to give another parameter, that's a
> > PITA.
> > If this doesn't fit your problem: could you post an example how you
> > would like to use your new feature?
>
> hmm... I have to think this through, but I think that pretty much solves
> my problem; I guess I thought way too complicated here,
> and I didn't look at the <file> element as solution (I kind off thought,
> it was only good for copying stuff, not XSLT processing...);
>
> Anyway, there is one little issue:
> when viewing a document generated like that (ie. with the file element,
> and XSLT processing), the navigation bar is generated,
> but doesnt show an active Entry; ie. all Sections and Entrys are in
> "normal" state, which might be a little confusing, since the user
> doesn't know, where he is;
> thats one of the reasons why I thought about a new Element similar to
> Section (I called it "EntryGroup"), where you could group
> files, that are supposed to appear under the same Entry;  you might
> think of an EntryGroup like a Deck in WML (group several
> pages (= WML cards) together);
>
>
> introducing a new Element to XWeb is not necessary, but how about
> changing XWeb behaviour a little:
> if a input file is to be processed by XSLT, XWeb generates the Structure
> XML fragment that is added to the
> XML file (for generating the navigation); Now, if you process an
> <entry>, you set the active attribute in it to "true"
> (or something like that), so the XSLT can show the Entry differently
> than an normal (inactive) Entry;
> This is not done when processing an <file>, since there is no active
> Entry here;
> Now the change: if XWeb processes a file, it searches for the first
> Entry before the <file> and sets this one active;
> It is a hack, but I guess it would achieve what I want; 

I don't think XWeb should do this, since this is a specific issue of 
your approach that probably wouldn't hold in many cases. You can use 
XSLT to do this or ...

> hmmm... how about changing Entry to allow <file>s as children, so you
> could tell XWeb: this file logically belongs to
> this Entry?  This might make the above described method easier...
> eg.
> <entry name="foo" sourceFile="foo.xml" targetFile="bar.html" 
> type="foobar">
>    <file sourceFile="page2.html" targetFile="page2.html" type="fluffy" >
> </entry> 

... you could do this approach in a slightly different form:

<section name="foo" sourceDir="." targetDir="." type="pageGroup">
   <entry name="foo" sourceFile="foo.xml" targetFile="bar.html" 
type="foobar"/>
   <file sourceFile="page2.html" targetFile="page2.html" type="fluffy"/>
</section>

Then handle sections of type "pageGroup" in a way that the first entry 
is used for navigation and the rest ignored. The section will be marked 
as active for each page in it so you can find the entry you want with:

   //section[file/@active='true']/entry[1]

(I didn't do any XPath for a while, I hope I got this right: we search 
for a <section> directly containing a <file> with the attribute "active" 
set to "true" and pick the first <entry>)

Admittably this is not as easy as it could be in your example, but I 
don't think it is too complicated or the case frequent enough to justify 
an additional structure element like the <entryGroup> which would be 
only another type of section. The idea with the nested files in <entry> 
sounds nice, though -- it makes sense for other <file>s, too. An example 
would be creating SVGs as part of a page: here the creation process 
wouldn't change but it would give some conceptual structure, the same 
for copying files that are somehow part of a page (images, applets, etc.).

I'll add this to the feature requests.

   Peter

Re: [Xweb-developers] Comments about XWeb

[murphee <wer...@ne...>]

Peter Becker wrote:

 >> change the XWeb source. Is there a proper solution for this, or would
 >> this require some change
 >> in the XWeb source?
 >
 > There is nothing I'd call a proper solution but changing the source
 > should be rather easy since this problem did occur before: if XWeb
 > generates multiple layouts from one website file, the layout
 > definitions have to be cleared, too.

 > Here is the code fragment responsible for this, found in
 > WebsiteProcessor.java at line 144ff. :
 >
 >            // clean up if there is another layout
 >            if( itLayout.hasNext() )
 >            {

  ... code snipped...

 > That's obviously not a nice way to solve the issue, but maybe it helps
 > with your problem, too. The way XWeb is called from the CLI is pretty
 > much specialized for this approach, that's one of the many things I'd
 > like to refactor.

hmm... I guess it might work, if I put a second *empty* Layout
Definition in the .xweb file, ... that would "flush"
the previously used Layout (and the styles,... defined in it);



 >> of the file in the sequence, which is not what  I want.  This is not
 >> a limited sample, the same goes for all Entrys that need to be
 >> made of several files, but should appear with the active same
 >> Entry-Button.
 >
 > [...]
 >
 > I am not sure if I understand you here.

  ... yeah, I thought so... it usually takes me several attempts to get
my thought straight (when putting them into writing);

 > 1) the document() function to include additional XML files works fine
 > in Saxon and AFAIK in Xalan, too. Hopefully I'll release the final 1.0
 > this week which will include an example where this approach is used
 > (result can be seen here: http://meganesia.int.gu.edu.au/~pbecker/kvo
 > -- the BibTeXML input file is searched for each persons publications
 > on their personal page, i.e. the descriptions of the persons are made
 > of a personName.xml file plus the bibtex.xml file for the publication
 > info)

Oh, good; I didn't know that XSLT 1.1 support was already in Saxon (I
knew about the Saxon-specific solution for mulitple document output);

 > 2) if you want to create multiple outputs from one XML file with only
 > one navigation entry you could use a combination of one <entry> and
 > multiple <file>s. I think this is conceptually ok (you have one entry
 > in the navigation, pointing to the first page and the others are just
 > files), the missing feature here is the ability to attach XSLT
 > parameters to the entries. At the moment you will have to create one
 > <documentType> for each page just to give another parameter, that's a
 > PITA.
 > If this doesn't fit your problem: could you post an example how you
 > would like to use your new feature?

hmm... I have to think this through, but I think that pretty much solves
my problem; I guess I thought way too complicated here,
and I didn't look at the <file> element as solution (I kind off thought,
it was only good for copying stuff, not XSLT processing...);

Anyway, there is one little issue:
when viewing a document generated like that (ie. with the file element,
and XSLT processing), the navigation bar is generated,
but doesnt show an active Entry; ie. all Sections and Entrys are in
"normal" state, which might be a little confusing, since the user
doesn't know, where he is;
thats one of the reasons why I thought about a new Element similar to
Section (I called it "EntryGroup"), where you could group
files, that are supposed to appear under the same Entry;  you might
think of an EntryGroup like a Deck in WML (group several
pages (= WML cards) together);


introducing a new Element to XWeb is not necessary, but how about
changing XWeb behaviour a little:
if a input file is to be processed by XSLT, XWeb generates the Structure
XML fragment that is added to the
XML file (for generating the navigation); Now, if you process an
<entry>, you set the active attribute in it to "true"
(or something like that), so the XSLT can show the Entry differently
than an normal (inactive) Entry;
This is not done when processing an <file>, since there is no active
Entry here;
Now the change: if XWeb processes a file, it searches for the first
Entry before the <file> and sets this one active;
It is a hack, but I guess it would achieve what I want;

hmmm... how about changing Entry to allow <file>s as children, so you
could tell XWeb: this file logically belongs to
this Entry?  This might make the above described method easier...
eg.
<entry name="foo" sourceFile="foo.xml" targetFile="bar.html" type="foobar">
    <file sourceFile="page2.html" targetFile="page2.html" type="fluffy" >
</entry>


Oh yeah:
Webbuilder currently doesnt show or recognize <file> elements, but that
just means, that they wont be shown
in the website structure tree of the GUI; I have to add that;

murphee

Re: [Xweb-developers] Comments about XWeb

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

Hello Murphee,

I'll check your program in the next days and answer your other posting 
then. Here are some answers to your comments first:

murphee wrote:

> howdy,
>
> when working on Webbuilder, I found some problems with XWeb, that
> I would like to show here:
>
> ******
>
> XWeb can only run once
>
> I wrote an XWeb Ant Task that allows you to use XWeb in Ant files.
> The XWeb Ant Task basically just calls the static  processWebsite()
> method in the WebsiteProcessor class.
> Now, it seems, that XWeb was written to be a commandline
> utility, i.e. that it will only be called, do its job and the quits.
> The problem is: it seems, that XWeb saves some  information about
> the file it processed in some static variables, and doesn't clear up 
> after
> a run. Now, if I run XWeb for a second in the same JVM (as it should with
> Webbuilder, and not just twice,...) with the same xweb-file,
> XWeb stops and complains that some SectionStyle has already been defined
> (obviously, stored in some field from the previous run on the same 
> xweb-file);
>
> I haven't found a proper way, to reInitialize XWeb from outside, and I 
> didnt have the time to
> change the XWeb source. Is there a proper solution for this, or would 
> this require some change
> in the XWeb source? 

There is nothing I'd call a proper solution but changing the source 
should be rather easy since this problem did occur before: if XWeb 
generates multiple layouts from one website file, the layout definitions 
have to be cleared, too.

Here is the code fragment responsible for this, found in 
WebsiteProcessor.java at line 144ff. :

            // clean up if there is another layout
            if( itLayout.hasNext() )
            {
                // clean up types (otherwise we get duplicates)
                DocType.clearTypes();
                SectionType.clearTypes();
                // remove all <img> elements in navigation structure
                removeImageElements( _DOM.getRootElement().getChild( 
"structure" ) );
                // call GC -- otherwise the new types will be removed later
                System.gc();
            }

That's obviously not a nice way to solve the issue, but maybe it helps 
with your problem, too. The way XWeb is called from the CLI is pretty 
much specialized for this approach, that's one of the many things I'd 
like to refactor.

> ********
>
> New Type in Structure Element: EntryGroup?
>
> One thing I stumbled on was, that I didn't find a way to create several
> output files from one XML input files. This is a problem of XSLT
> (that should  be resolved in XSLT 1.1), but also a problem of XWeb
> (I think);
> Let me give you an example, of when I had the problems:
> I wanted to make an InstallableDocument Type, that would allow users
> to make a photo album -like set of XHTML pages.  Eg. you have several
> photos, and you want to make a "tour" of the pages, i.e. you can click
> through a sequence of images; each of these would the require a seperate
> output file; OK... that would still be possible...
> BUT now the problem: all the pages in this photo sequence, would have to
> appear under the same (active) Entry, ie. all the pages in there belong
> to one Entry, ie. one Entry would be made of several files; This is not
> possible, because if I add each file as an Entry, I get an Entry for each
> of the file in the sequence, which is not what  I want.  This is not a 
> limited sample, the same goes for all Entrys that need to be
> made of several files, but should appear with the active same 
> Entry-Button.

[...]

I am not sure if I understand you here. Maybe some hints help:

1) the document() function to include additional XML files works fine in 
Saxon and AFAIK in Xalan, too. Hopefully I'll release the final 1.0 this 
week which will include an example where this approach is used (result 
can be seen here: http://meganesia.int.gu.edu.au/~pbecker/kvo -- the 
BibTeXML input file is searched for each persons publications on their 
personal page, i.e. the descriptions of the persons are made of a 
personName.xml file plus the bibtex.xml file for the publication info)

2) if you want to create multiple outputs from one XML file with only 
one navigation entry you could use a combination of one <entry> and 
multiple <file>s. I think this is conceptually ok (you have one entry in 
the navigation, pointing to the first page and the others are just 
files), the missing feature here is the ability to attach XSLT 
parameters to the entries. At the moment you will have to create one 
<documentType> for each page just to give another parameter, that's a PITA.

If this doesn't fit your problem: could you post an example how you 
would like to use your new feature?

   Peter

[Xweb-developers] Comments about XWeb

[murphee <wer...@ne...>]

howdy,

when working on Webbuilder, I found some problems with XWeb, that
I would like to show here:

******

XWeb can only run once

I wrote an XWeb Ant Task that allows you to use XWeb in Ant files.
The XWeb Ant Task basically just calls the static  processWebsite()
method in the WebsiteProcessor class.
Now, it seems, that XWeb was written to be a commandline
utility, i.e. that it will only be called, do its job and the quits.
The problem is: it seems, that XWeb saves some  information about
the file it processed in some static variables, and doesn't clear up after
a run. Now, if I run XWeb for a second in the same JVM (as it should with
Webbuilder, and not just twice,...) with the same xweb-file,
 XWeb stops and complains that some SectionStyle has already been defined
(obviously, stored in some field from the previous run on the same 
xweb-file);

I haven't found a proper way, to reInitialize XWeb from outside, and I 
didnt have the time to
change the XWeb source. Is there a proper solution for this, or would 
this require some change
in the XWeb source?

********

New Type in Structure Element: EntryGroup?

One thing I stumbled on was, that I didn't find a way to create several
output files from one XML input files. This is a problem of XSLT
(that should  be resolved in XSLT 1.1), but also a problem of XWeb
(I think);
Let me give you an example, of when I had the problems:
I wanted to make an InstallableDocument Type, that would allow users
to make a photo album -like set of XHTML pages.  Eg. you have several
photos, and you want to make a "tour" of the pages, i.e. you can click
through a sequence of images; each of these would the require a seperate
output file; OK... that would still be possible...
BUT now the problem: all the pages in this photo sequence, would have to
appear under the same (active) Entry, ie. all the pages in there belong
to one Entry, ie. one Entry would be made of several files; This is not
possible, because if I add each file as an Entry, I get an Entry for each
of the file in the sequence, which is not what  I want.  
This is not a limited sample, the same goes for all Entrys that need to be
made of several files, but should appear with the active same Entry-Button.

(I hope I could make myself clear up to now);

I haven't found a solution for this yet.   I thought about using a 
special Section,
where I would just show the Section Buttons, and not the buttons of the
contained Entrys, but that would lead to a huge mess (creating and 
managing Section-,
ImageStyles, special changes to the XSLT file (that creates the 
Navigation),...
In short: it would neither look logical, nor would it be easy to program.

I think the solution would be a new Element in the Structure Element:
you have Section and Entry, and I think a "EntryGroup" is needed.
This would be of type "directory" (as defined in the website.xsd file)
like Section. It could contain Entrys; it would take the first Entry as its
default page (which is shown when you click on the EntryGroups button);
BUT it would take a documentType as its Type, so that it's button would
seem like a normal Entry-button.

This would make it easier, to bundle several files under one Entry 
navigation item,
without having to resort to difficult solutions; it would also make it 
easier for
Frontends (esp. Webbuilder) to handle files that logically belong together;

hmm... I am not sure if  I made myself clear, but hope someone might somehow
get it...

murphee

[Xweb-developers] GUI Frontend for XWeb: Webbuilder

[murphee <wer...@ne...>]

howdy,

it sure got quiet on this list...
Well anyway, some months ago I posted some info about me wanting to
write an GUI Frontend for XWeb using Java. This was for a project
at university (and because I wanted a cool GUI for XWeb).

Well, the University project is over, and if you are interested in XWeb
you might want to take a look at the result here:
http://www.angelfire.com/co/werners/webbuilder/

I didn't have enough time to do really everything I wanted... and less...
Basically, the programm is more a working prototype, but I'll use the
old  "Release early and often" paradigm.

There is some information provided in the package that you can download,
but for a higher level overview, you might want to take a look at the
slides of my project presentation
  http://www.sbox.tugraz.at/home/w/werner/pres/img0.html

I especially think, that the Installable/Pluggable DocumentTypes are
a good way to make XWeb even more extensible.
In short, an Instalable DocumentType, is a way to bundle the necessary
files (and Code) needed for a DocumentType (= DocumentStyle).
There is one sample DocmentType, called "webbuilder.FAQ";
I borrowed the XSLT for the FAQList (provided in the XWeb distro)
and used it for this Type. The "webbuilder.FAQ" DocumentType
(= DocumentStyle) also (and that makes it cool) with a GUI that
allows you to easily edit FAQList XML files (without writing XML
code), thus providing the input files for the FAQList XSLT file.
I.e. you can just create an Entry of type "webbuilder.FAQ" and
automatically use the GUI (for editing the XML files) that was
provided in the DocumentType.
Installable DocumentTypes (XSLTs, Code) are bundled in .jar files;
To install a DocumentType, just copy its .jar file to the
$WEBBUILDERHOME/documentTypes  directory; they are all
automatically loaded when you launch Webbuilder.



If you want to give it a spin, you just have to download the programm,
extract the archive, set the WEBBUILDERHOME env var, and launch
the program with eg.
$WEBBUILDERHOME/webbuilder.sh  ../examples/wbmurpheeonline/project.xml
(you can pass in the name of a project.xml file as an argument), although
to be able to build the website, you should CD to the website-project dir
and launch Webbuilder from there (there are some yet unsolved problems
with the working directory and Ant);

If you launch Webbuilder without params, you can choose between opening an
existing project or creating a new one. If you create a new one, mind 
you that
the name you give for the new website, will be used as directory name (a 
website
project is contained in a directory whose root contains the project.xml 
and the
website.xweb files);

Ad project.xml:
This is an Ant file that contains information about the website project 
and the
build process(es). This is not completeley thought out yet, but it works 
... sort of...

Ad website.xweb:
If you want to view/edit/try some XWeb website of yours with Webbuilder, 
you
might run into trouble, if your Sourcefiles are not in a directory 
called "input".
I hardcoded that into some Java sources, so Webbuilder won't work properly
if you have your input files in a directory other that 
"$PROJECTROOT/input".
(And if you want to use your XWeb Website with Webbuilder, you should only
work on a copy!! As I said, Webbuilder is basically a prototype, and can 
at any time
go crazy.......).


About building the website:
This does not really work properly yet. One reason is, that there are 
some problems
with Ant, that I have to solve yet (eg. programmatically setting Ants 
working dir);
The other reason is, that there is a XWeb flaw, that prevents building 
the website
more than once in a JVM ... (read my Mail "Comments about XWeb");

I hope I provided enough information about the tool, so that people can 
try it.
If you have any questions, don't hesitate to drop me a mail.

I plan to maintain an futher develop Webbuilder, possibly creating a 
Sourceforge
account for it, but I have to prepare for some exams right now, so I 
don't have
the time to make proper documentation or a prober website for it;
I just wanted to get it out there, in case someone might find it 
interesting.


murphee

Re: [Xweb-developers] gui for cv.xthml

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

Hello Peter

> I tried to find some introducing documentation (howto or tutorial) but
failed.
__I presume you're referring to xybrix? If so, then you can  check out the
tutorials I did for it at
http://www.dennisgdaniels.com/questionmethodhtml/tutorials.html
do a search for xybrix and you'll see a lot of stuff...and a few for xweb
too ;)
keep in mind that they are 'mostly' sequential screen grabs ...'rule of
thumb' with xybrix is to build your forms with the app constructor ...
> With XForms compliance it surely sounds interesting.
___it's not fully compliant with xforms read
http://www.jbrix.org/kits/xybrix/updates/2001-11-12.html for more info

>Can you point me to some
> online documentation or do I have to download the distribution?
___You'll probably need to download it...I do believe it was the easiest app
I've ever started...super quick. What's really nice about Xybrix is that the
documentation is 'built in'! It's a really sweet feature in Xybrix! External
docs...hmm don't know. I just jumped in... Just remember when building your
forms in the app constructor you give your forms a ref of "." Ck out
XFormsExampleTwo and you'll see how the whole thing is put together pretty
quickly...
hth
Dennis

>
> Thanks,
>    Peter
>
>
> Dennis Daniels wrote:
>
> > 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
> >
>
  ------------------------------------------------------------------------
> >                Name: xweb.app
> >    xweb.app    Type: unspecified type (application/octet-stream)
> >            Encoding: quoted-printable
>
>
>
>
> _______________________________________________
> XWeb-Developers mailing list
> XWe...@li...
> https://lists.sourceforge.net/lists/listinfo/xweb-developers
>

Re: [Xweb-developers] gui for cv.xthml

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

Hello Dennis,

I tried to find some introducing documentation (howto or tutorial) but failed.
With XForms compliance it surely sounds interesting. Can you point me to some
online documentation or do I have to download the distribution?

Thanks,
   Peter


Dennis Daniels wrote:

> 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
>
>   ------------------------------------------------------------------------
>                Name: xweb.app
>    xweb.app    Type: unspecified type (application/octet-stream)
>            Encoding: quoted-printable

Re: [Xweb-developers] gui for cv.xthml

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

Hello Murphee
I cked out your slides and found them interesting...Ant does offer quite a
few bells and whistles! Your diagrams remind me a lot of some code
generation diagrams I've seen in the past (www.craigc.com has some
interesting things to say about CG and his book is quite a good read)

Re:xybrix
I'm in 'regular contact' with Jim Wissner, the developer of xybrix, and
though the man is very busy, he has integrated dom4j into xybrix which
offers some very exciting stuff, like DTD read/write support, and he's
making xybrix 'even more modularized'.

Frankly, as a 'non-programmer' I find xybrix easy to manage, and has great
potential as a GUI for xml.

I'd be interested in seeing what you've put together...My interest in a GUI
xml is in fact for building a more modular help system structure...faqs,
helpdocs, etc. I love xybrix's 'auto help creator'. I think that part is
absolute genius on Jim's part.

Thanks for the tip on your app and I'm looking forward to hearing more about
it!
Cheers
Dennis
----- Original Message -----
From: "murphee" <wer...@ne...>
To: <xwe...@li...>
Sent: Tuesday, January 29, 2002 5:06 PM
Subject: Re: [Xweb-developers] gui for cv.xthml


> Dennis Daniels wrote:
>
> >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.
> >
>  ...stuff snipped...
>
> >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.
> >
> In case you're looking for a GUI for XWeb:
> I have been busy working on one for the last 2-3 months as a
> project for university.  It just a prototype yet and doesnt implement
> the full XWeb file format, but the basics are defined and coded; they
> just need to be fleshed out.
> The tool uses Ant for the building the Website (using an own little
> XWeb Ant task).
> The university project was (finally...) finished on monday. I still have
> to put the thing in a distributable form, and build some documentation,
> but I guess I can put it out there in about 2 weeks (I will post a
> notification
> on this list).
>
> About the use of Xybrix:
> I considered this, but couldnt implement it due to a lack of time. But I
> am considering
> it to facilitate writing Editors for custom XML files. My tool includes
> can be easily enhanced
> by types (and visual editors) for XML files.  Currently I provide a
> simple editor, that
> allows to edit FAQlist files (there is a sample FAQList datafile and
> faq2xhtml.xsl in
>  the XWeb distro, that I used for this).
>
> In case you're still reading this mail, you can take a look at my
> presentation slides for the
> project here: http://www.sbox.tugraz.at/home/w/werner/pres/img0.html
>
>
> murphee
>
>
> _______________________________________________
> XWeb-Developers mailing list
> XWe...@li...
> https://lists.sourceforge.net/lists/listinfo/xweb-developers
>

Re: [Xweb-developers] gui for cv.xthml

[murphee <wer...@ne...>]

Dennis Daniels wrote:

>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.
>
 ...stuff snipped...

>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.
>
In case you're looking for a GUI for XWeb:
I have been busy working on one for the last 2-3 months as a
project for university.  It just a prototype yet and doesnt implement
the full XWeb file format, but the basics are defined and coded; they
just need to be fleshed out.
The tool uses Ant for the building the Website (using an own little
XWeb Ant task).
The university project was (finally...) finished on monday. I still have
to put the thing in a distributable form, and build some documentation,
but I guess I can put it out there in about 2 weeks (I will post a 
notification
on this list).

About the use of Xybrix:
I considered this, but couldnt implement it due to a lack of time. But I 
am considering
it to facilitate writing Editors for custom XML files. My tool includes 
can be easily enhanced
by types (and visual editors) for XML files.  Currently I provide a 
simple editor, that
allows to edit FAQlist files (there is a sample FAQList datafile and 
faq2xhtml.xsl in
 the XWeb distro, that I used for this).

In case you're still reading this mail, you can take a look at my 
presentation slides for the
project here: http://www.sbox.tugraz.at/home/w/werner/pres/img0.html


murphee