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

[Xweb-developers] A patch for the website.xsd

[vito p. <jo...@si...>]

I don't no if the project is still alive, however
i have found some error in the website.xsd file.
If anyone is interested, the patch is attached




--=20

-vp

_________________________________________________________________________
   Vito Piserchia - Reparto Informatico
  Societ=E0 Italiana di Fisica
  via Saragozza 12 40123 - BOLOGNA
  tel: 0513396742 - fax : 051581340

-------------------------------------------------------------------------
Important Email Information
The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this email
by anyone else is unauthorized. If you are not the intended recipient, an=
y
disclosure, copying, distribution or any action taken or omitted to be
taken in reliance on it, is prohibited and may be unlawful. If you are no=
t
the intended addressee please contact the sender and dispose of this
e-mail.
-------------------------------------------------------------------------

[Xweb-developers] FASD project: Online survey launched

[Benno L. <ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I
kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The
questionnaire consists of 53 questions and you will need about 15 minutes to
complete it.

With the FASD project (Fun and Software Development) we want to define the
motivational significance of fun when software developers decide to engage
in Open Source projects. What is special about our research project is that
a similar survey is planned with software developers in commercial firms.
This procedure allows the immediate comparison between the involved
individuals and the conditions of production of these two development
models. Thus we hope to obtain substantial new insights to the phenomenon of
Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under
http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please
see http://fasd.ethz.ch/qsf/mailinglist_de.html for registration to this
mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[Xweb-developers] Re: Stylesheet for 3-layer-Navigation?

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

Tuesday, February 3, 2004, 9:40:37 AM, you wrote:

> I am just about to fly back to AUS, so you have to wait for a more
> detailed answer. Some thoughts:
> - you would need extra parameters and/or CSS styles to handle subsectio=
ns

Done that. They are called td.navNormalSubEntry / td.navActiveSubEntry

> - the XSLT has to be checked how it handles the sections and entries.=20
> You would need either a mode once you are in a section to distinguish=20
> from the standard <section> match, or you could try to match=20
> "section/section" with a higher priority than "section" itself. I would=
=20
> have to test that myself.

I have added 2 additional modes:
- insertEntryButton
  This is used to render the second layer of navigation (normally only
  entries, now also sections)
- insertEntrySubButton
  Used to render the third layer of navigation (only entries)
I have added new template matches for 'section', mode=3DinsertEntryButton=
, to
render the sections in the second layer like entries, and one for
'entries', mode=3DinsertEntrySubButton, to render the third layer.
Additionally, the third layer is rendered for the left navigation bar (an=
d
only there).

There is much copy&paste involved, and it only works in the left navigati=
on
bar, using non-nested navigation. But at least it works :)
I will try to shorten the XSLT sheet a little bit, and make it easier to
understand.

Maybe its better to create multiple versions of the stylesheets - one for
each navigation type. Maybe thats easier to understand (and to change).

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

Re: [Xweb-developers] Stylesheet for 3-layer-Navigation?

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

Hendrik Lipka wrote:

>Hello Peter,
> 
>Monday, February 2, 2004, 9:09:47 PM, you wrote:
>
>  
>
>>Hi Hendrik,
>>    
>>
>
>  
>
>>I don't think I ever actually did more than two layers of navigation, 
>>but XWeb won't stop you. Nesting <section>s is no problem at all, the 
>>    
>>
>
>I know, I have already done that.
>
>  
>
>>only thing you have to make sure is that the stylesheet for the 
>>navigation handles this. The generic one in the distribution is not 
>>meant for this, although it could probably be extended towards a third 
>>layer.
>>    
>>
>
>
>Exactly that was my question :) I have already displayed the section inside
>another section, but it is rendered with the wrong colors, and the third
>layer is not displayed :(
>  
>
I am just about to fly back to AUS, so you have to wait for a more 
detailed answer. Some thoughts:
- you would need extra parameters and/or CSS styles to handle subsections
- the XSLT has to be checked how it handles the sections and entries. 
You would need either a mode once you are in a section to distinguish 
from the standard <section> match, or you could try to match 
"section/section" with a higher priority than "section" itself. I would 
have to test that myself.

  Peter

Re: [Xweb-developers] Stylesheet for 3-layer-Navigation?

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

Hi Hendrik,

I don't think I ever actually did more than two layers of navigation,=20
but XWeb won't stop you. Nesting <section>s is no problem at all, the=20
only thing you have to make sure is that the stylesheet for the=20
navigation handles this. The generic one in the distribution is not=20
meant for this, although it could probably be extended towards a third=20
layer.

  Peter



Hendrik Lipka wrote:

>Hello,
>
>the supplied generic.xsl allows only for 2-Layer-navigation (sections an=
d
>entries). Until recently, this was sufficient for my website, but now I'=
m
>in need for a third layer.
>
>Has anybody done this before?
>
>I was already able to include a 'section' inside a 'section', so that it
>would be displayed beside the normal entries, and it is already clickabl=
e.
>But it is rendered with section colors (not entry colors) and I don't kn=
ow
>how to add the third layer to the navigation bar (everything is on the l=
eft
>side).
>
>Any hints?
>
>Thanks,
>
>hli
>--
>M=F8=F8se trained to mix concrete and                                 He=
ndrik Lipka
>sign complicated insurance forms                           hendrik.lipka=
@gmx.de
>                                                            www.hendrikl=
ipka.de
>
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>XWeb-Developers mailing list
>XWe...@li...
>https://lists.sourceforge.net/lists/listinfo/xweb-developers
>
>
> =20
>

[Xweb-developers] Stylesheet for 3-layer-Navigation?

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

Hello,

the supplied generic.xsl allows only for 2-Layer-navigation (sections and
entries). Until recently, this was sufficient for my website, but now I'm
in need for a third layer.

Has anybody done this before?

I was already able to include a 'section' inside a 'section', so that it
would be displayed beside the normal entries, and it is already clickable.
But it is rendered with section colors (not entry colors) and I don't kno=
w
how to add the third layer to the navigation bar (everything is on the le=
ft
side).

Any hints?

Thanks,

hli
--
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] preserve ratio in imageCopy

[Ralf P. <ra...@pu...>]

Hi,

creating thumbnails width the imageCopy-docstyle is a cool feature,
which could save me a lot of time. But for my galleries i need to
scale images with (max)height and (max)width where the width/height-
ratio should be kept:

<documentStyle type="image.thumb">
   <imageCopy width="135" height="135"/>
</documentStyle>

The code for scaling would be the following (ImageCopyDocType.java:113):

} else if (this.width != -1 && this.height != -1) {
     lastWidth = oldWidth;
     lastHeight = oldHeight;
     if (lastWidth > width) {
         lastHeight = (lastHeight * width) / lastWidth;
         lastWidth = width;
     }
     if (lastHeight > height) {
         lastWidth = (lastWidth * height) / lastHeight;
         lastHeight = height;
     }
}

Would iit be possible, to integrate this feature into XWeb?
Another possible solution would be adding new maxHeight and maxWidth
attributes to the imageCopy tag.

Regards,
Ralf

Re: [Xweb-developers] XWeb and JTidy

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

Hi Murphy,

sorry for the delay -- still catching up with the mails from the holiday 
season.

The problem you describe is something I noticed, too. I'd sometimes like 
to have people using something like Mozilla+TortoiseCVS or similar to 
maintain the website, with the updates done automatically on the server. 
That does require something like JTidy.

I'd say there are two options (as usual): the quick and dirty and the 
nice one. Quick and dirty is extending the XSLT specific code to have 
some option for JTidy. That would mean putting the JTidy calls into the 
XSLDocType/XSLDocument classes. Not nice at all, but that's why it is 
the quick and dirty way.

Way better would be turning the way XWeb processes files into something 
stream/pipe-based. I planned that many times before, the simple version 
of this is to distinguish two types of stream (binary, sax) and to 
convert between them if required (i.e. XML parsing/writing). Then 
different processors would have a single input and output and could do 
different things, which can be used to model XSLT chains, your 
JTidy->XSLT requirement or more complex options involving things like 
CLI scripting. The pipe starts with reading the input file and ends with 
writing the output file.

Shouldn't be too hard, but the changes to XWeb would be significant. It 
would take XWeb closer to other projects like Lagoon or Transmorpher, 
too. I'd like to do that anyway, but I don't know when I am getting 
around to do it. The usual problem, esp. in the chaotic times I tend to 
live :-)

  Peter



murphee (Werner Schuster) wrote:

> howdy Peter,
>
> I am about to use XWeb to maintain a Website, well actually I am
> building the skeleton for a website, and other users will maintain
> it and provide content.
>
> Now, my problem is, those users, while tech savy, don't know a lot
> about XML, and even if they do, I don't want to force them to
> produce valid XHTML as input (I can picture myself getting mails
> telling me that "XWeb crashes with an exception", just because
> some input file was not valid).
>
> Now, this can be solved by pre-processing each file with JTidy;
> Initially I wanted to do this with Ant (basically just processing
> each file with JTidy and writing the resulting files to a
> temp directory, and then using that directory as input for XWeb;
> I won't do that right now, for some reasons, but might reconsider
> in the future).
>
> Now, I think it would be best to simply adapt XWeb to simply
> pre-process a file with JTidy before handing it to XSL;
> I found that I could simply do that in XSLDocument, where
> you open the file and generate it's DOM tree from it;
> Is this the only place that I have to change, or do I have
> to adapt something else?
>
>
>
> murphee

[Xweb-developers] XWeb and JTidy

[murphee (W. Schuster) <wer...@ne...>]

howdy Peter,

I am about to use XWeb to maintain a Website, well actually I am
building the skeleton for a website, and other users will maintain
it and provide content.

Now, my problem is, those users, while tech savy, don't know a lot
about XML, and even if they do, I don't want to force them to
produce valid XHTML as input (I can picture myself getting mails
telling me that "XWeb crashes with an exception", just because
some input file was not valid).

Now, this can be solved by pre-processing each file with JTidy;
Initially I wanted to do this with Ant (basically just processing
each file with JTidy and writing the resulting files to a
temp directory, and then using that directory as input for XWeb;
I won't do that right now, for some reasons, but might reconsider
in the future).

Now, I think it would be best to simply adapt XWeb to simply
pre-process a file with JTidy before handing it to XSL;
I found that I could simply do that in XSLDocument, where
you open the file and generate it's DOM tree from it;
Is this the only place that I have to change, or do I have
to adapt something else?



murphee
-- 
Werner Schuster (murphee)
Student of SoftwareEngineering and KnowledgeManagement
Maintainer of the OGO-JOGI Project @ http://ogo-jogi.sourceforge.net/

Re: [Xweb-developers] Reactivating development

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

murphee (Werner Schuster) wrote:

>>> Peter Becker wrote:
>>> murphee wrote:
>>>
>>>> Your bus described in the presentation -- is that a Bean InfoBus?
>>>
>>> Nope, but it was influenced by it InfoBus (and jEdits EditBus);
>>> Webbuilder was designed to be very extensible and something like
>>> that was necessary for that;
>>
>> What was the reason not to go with an InfoBus? I am currently trying to
>> understand the Bean world and I wonder if I should use some of the ideas
>> in XWeb itself.
>
>
> InfoBus is basically for connecting data sources; if I remember 
> correctly, it was built by Lotus (for their e...-something Java office
> suite) and then donated (or something like that) to Sun ... who 
> immediateley started working hard on ignoring it... sometimes I really
> don't understand what the people at Sun are thinking (same thing with
> Jini, which, after the first months of press-brooha, was simply 
> ignored...);

Sun is a big company, you have to expect a bit of SNAFU in there :-) And 
it seems neither you nor Hendrik were two impressed with the InfoBus.

> Well, anyway the Bus & Channel structure in Webbuilder is for
> sending Events; the idea was basically stolen from jEdits EditBus;
> One thing I changed was to allow for several channels; the reason
> was to make the whole thing scaleable; if all Events are sent on one
> bus, everyone gets every Event (as far as I understood EditBus); if
> the application reaches a certain amount of traffic, that must be
> limiting performance;

Sounds quite like the EventBroker class I use in our applications. It 
implements a publish/subscribe pattern based on event hierarchies. Each 
broker creates an event context, to which listeners can subscribe. 
Brokers are listeners themself to allow event delegation without 
bridges. The performance is probably not too good, though -- we rely 
heavily on RTTI for this, both the event and the subject of the event 
get checked via "instanceof". Never profiled it against simpler 
approaches, although I suspect that for application-level events it is 
probably not that important. Our 2D canvas class still uses it -- that 
should probably be fixed towards using a standard listener interface.

[..]

>
>>> Oh yeah... running JTidy before Xweb would be useful, if you want
>>> to import non-XHTML input files (this would make XWeb more 
>>> userfriendly,
>>
>> I defintely want JTidy support within XWeb, it seems to be too important
>> to need extra tools. The XHTML requirement for things like the generic
>> stylesheet coming with the distribution is a bit of a drawback.
>
>
> Hmm... how do you want to integrate JTidy into XWeb? Simply call it 
> before using an input file? Or if the XML Parser complains that the
> file is not well formed;

This is more for the stream idea. What I'd like to do is something like 
this:

<process ...>
  <jtidy/>
  <xslt .../>
  <xslt. .../>
</process>

The file would start of as a standard IO stream, and gets passed to 
JTidy as such. The JTidy output would still be an IOStream (I guess), 
but it should be implicitely converted to SAX since the XSLT would use 
SAX. Between the two XSLTs no conversion would be necessary, at the end 
the SAX stream would be turned into an IOStream for output. The idea 
would be defining these processes somewhere and using them in the docTypes.

>> chance to be found than yet another SF project without any activity. But
>> it's your choice of course. And there is the licensing issue, at the
>> moment XWeb is still public domain. The thing with licenses is that I
>> don't really want to care, but sometimes I feel I should :-)
>
>
> er... when you say public domain, you mean GPL? (Can't remember what
> XWebs license was...);

No, public domain, which means no license. It means anyone can do 
anything with it, a bit like not being owned. The only problem I have 
with this approach is that it has no warranty exclusion and 
unfortunately we live in times where people try to take less and less 
responsibility for what they do ;-)

I am not a fan of the GPL since I don't like telling people what to do. 
Not that I am not opiniated, but in the end everyone should do what they 
think is right. And revolutions tend to create new governments :-)

I prefer BSD- or Apache-style since simple and quite basic, or the Open 
Software License with the anti-IP attitude 
(http://www.opensource.org/licenses/osl-2.0.php), but unfortunately as 
easy to read as the average EULA -- which is a rather bad feature.

Personally I am quite willing to take the risk of the PD approach, but I 
suspect that before I accept contributions I should probably handle the 
licensing question.

  Peter

Re: [Xweb-developers] Re: Reactivating development

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

murphee (Werner Schuster) wrote:

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

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

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

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

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

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

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

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

  Peter

Re: [Xweb-developers] Re: Reactivating development

[murphee (W. Schuster) <wer...@ne...>]

Peter Becker wrote:
> Hendrik Lipka wrote:
> The point I want to make is that Ant is a developers tool and that the 
> XWeb integration needed in this context seems to be only the XWeb task 
> for Ant. The frontend I imagine would be more for someone setting up a 
> small website without many IT skills -- I suspect Webbuilder has a 
> different target audience,

Not really; it was actually designed to be customizable for all kinds
of target audiences;
The idea behind using Ant was not so much to appeal to developers,
but to have a build process that is as open as possible;
Don't think of Ant (in Webbuilder) as the developers tool Ant, but as...
well call it an "API" for a build process; this makes it easy for
Plugins or DocumentTypes to add their own tasks to the build process;
they have the wide variety of Ant tasks at their disposal; another
advantage is to allow advanced users to modify the build process
themselves (by modifying the build file)... or to allow them
to fix the build file in case Webbuilder has messed it up;

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



 > also I think that audience is hard to target with a GUI.

Not necessarily; one aspect of Webbuilder was to allow for DocumentTypes
to come with their own GUI; ie. the FAQ DocumentType came with the FAQ
XSLT Stylesheet (I think stol^H^H^H^Hcopied from XWeb) and a simple
GUI that allows for easily entering and modifying the FAQ list;
the point is, that the FAQs are stored in an XML file; even with a
good editor (== vi) you would have a lot of overhead writing the file
yourself; with the tool, you would not have to look at the XML file;

Or imagine a DocumentType "NewsList", where you enter the news item
in a GUI and hit "deploy"; the GUI would slap a timestamp on the news 
item, update your RSS file and then arrange for a Rebuild of the Website;


 > Just look at how many people still code Java with vi or
> Emacs ;-) I never used much in terms of IDEs for C++, but with Java and 
> Refactoring it is a bit different.

And don't forget JUnit integration... that's one of the best features
in Eclipse;


murphee
-- 
Werner Schuster (murphee)
Student of SoftwareEngineering and KnowledgeManagement
Maintainer of the OGO-JOGI Project @ http://ogo-jogi.sourceforge.net/

Re: [Xweb-developers] Reactivating development

[murphee (W. Schuster) <wer...@ne...>]

>> Peter Becker wrote:
>> murphee wrote:
>>> Your bus described in the presentation -- is that a Bean InfoBus?
>> Nope, but it was influenced by it InfoBus (and jEdits EditBus);
>> Webbuilder was designed to be very extensible and something like
>> that was necessary for that;
> What was the reason not to go with an InfoBus? I am currently trying to
> understand the Bean world and I wonder if I should use some of the ideas
> in XWeb itself.

InfoBus is basically for connecting data sources; if I remember 
correctly, it was built by Lotus (for their e...-something Java office
suite) and then donated (or something like that) to Sun ... who 
immediateley started working hard on ignoring it... sometimes I really
don't understand what the people at Sun are thinking (same thing with
Jini, which, after the first months of press-brooha, was simply 
ignored...);

Well, anyway the Bus & Channel structure in Webbuilder is for
sending Events; the idea was basically stolen from jEdits EditBus;
One thing I changed was to allow for several channels; the reason
was to make the whole thing scaleable; if all Events are sent on one
bus, everyone gets every Event (as far as I understood EditBus); if
the application reaches a certain amount of traffic, that must be
limiting performance;



>> Generally updating input files, like regenerating them from DB
>>  sources, ...
> I don't see that as compelling, a little UNIX script would do the same.
> Of course being able to call XWeb from Ant is nice to create
> cross-platform solutions, but I don't see the need for a further
> integration.

hmmm... OK;


 > The Ant task as you described -- just called the main
> process from within Ant, seems quite appropriate. Maybe some extra
> options like configuring the baseURL or some parameters might be helpful.

yup; currently it can only set the previewFlag (I think);


>> Oh yeah... running JTidy before Xweb would be useful, if you want
>> to import non-XHTML input files (this would make XWeb more userfriendly,
> I defintely want JTidy support within XWeb, it seems to be too important
> to need extra tools. The XHTML requirement for things like the generic
> stylesheet coming with the distribution is a bit of a drawback.

Hmm... how do you want to integrate JTidy into XWeb? Simply call it 
before using an input file? Or if the XML Parser complains that the
file is not well formed;

> chance to be found than yet another SF project without any activity. But
> it's your choice of course. And there is the licensing issue, at the
> moment XWeb is still public domain. The thing with licenses is that I
> don't really want to care, but sometimes I feel I should :-)

er... when you say public domain, you mean GPL? (Can't remember what
XWebs license was...);


murphee
-- 
Werner Schuster (murphee)
Student of SoftwareEngineering and KnowledgeManagement
Maintainer of the OGO-JOGI Project @ http://ogo-jogi.sourceforge.net/

[Xweb-developers] Re:Reactivating development

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

Tuesday, November 11, 2003, 12:24:55 AM, you wrote:

> for this type of communication anyway. But I won't give you my "Usenet
> is so much cooler"-talk right now ;-)

You don't need to - I'm a regular Usenet user...

> Going from text editor + CLI to tools such as IDEA and then Eclipse
> (won't go into the details of that change, it is not that I call Eclips=
e=20
> better) changed my coding style significantly. It is not just easier or=
=20
> quicker, it is completely different. The availability of refactoring an=
d=20
> templates makes some things easy that I considered to hard most of the=20
> time before the change of tools.

"Now I can spend more time thinking because I don't need to type so much"
Using a good IDE (especially with really good refactoring and code
navigation abilities like IDEA) one writes better code faster.

>>No, not really. What I really want (and hopefully will write in the nex=
t
>>time) is a 3-way-diff:
> It is probably not too hard to write such an Ant task. Actually it

Its not difficult, just a little bit of work :) I also want to be able to
diff JAR/ZIP-Files, to generate patch-sets for my applications (to reduce
the download size).

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

Re: [Xweb-developers] Re:Reactivating development

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

Hendrik Lipka wrote:

>Monday, November 10, 2003, 1:31:13 PM, you wrote:
>
>  
>
>>[redirected back to list, fully quoted]
>>    
>>
>
>Sometimes I forget to do a 'reply to all' :(
>  
>
I thought so -- I know the problem :-) A pity we have to misuse email 
for this type of communication anyway. But I won't give you my "Usenet 
is so much cooler"-talk right now ;-)

>>The point I want to make is that Ant is a developers tool and that the
>>    
>>
>
>ACK. But building a web site _is_ development (its also programming in some
>kind), so why not using developer tools?
>  
>
That's a developer's attitude towards website creation. I think many 
website authors think of it more in terms of writing a set of documents. 
I'd really like to cater for both audiences.

>>XWeb integration needed in this context seems to be only the XWeb task 
>>for Ant. The frontend I imagine would be more for someone setting up a 
>>small website without many IT skills -- I suspect Webbuilder has a 
>>different target audience, also I think that audience is hard to target 
>>with a GUI.
>>    
>>
>
>A real good GUI fore XWeb would also handle some parts of Ant scripting
>(e.g. for CVS or FTP access).
>  
>
Maybe there is room for two GUIs, but I wouldn't really base the 
Dreamweaver clone (aiming high here) on Ant -- the underlying notion of 
a "build" would probably shine through the GUI, and I don't think it 
suits the application. I guess the Ant integrated one I'd like to see as 
Eclipse plugin, which would give an XML editor, access to Ant and a nice 
integration -- but that won't help anyone who isn't using Eclipse. I 
wonder how hard it would be to support a bunch of IDEs with some 
framework. I guess hard, esp. since Eclipse uses a different windowing 
toolkit than IDEA, JBuilder or anything else.

>>Just look at how many people still code Java with vi or 
>>Emacs ;-) I never used much in terms of IDEs for C++, but with Java and 
>>Refactoring it is a bit different.
>>    
>>
>
>[OT]
>  
>
I don't mind some slightly off-topic discussions (as you might have 
noticed). I think the technical discussions help understand each others 
coding approaches and style and sometimes good ideas might pop up.

>Only in my early days I coded w/o a IDE. just because on the Commodores
>these days they weren't this much...
>But today the lack of a good IDE is a real problem for learing a new
>language - such a thing can decide about being productive with a language
>or not...
>  
>
Going from text editor + CLI to tools such as IDEA and then Eclipse 
(won't go into the details of that change, it is not that I call Eclipse 
better) changed my coding style significantly. It is not just easier or 
quicker, it is completely different. The availability of refactoring and 
templates makes some things easy that I considered to hard most of the 
time before the change of tools.

>  
>
>>>- I want to call a _single_ program/script, which should do everything:
>>> - generate project documentation in XML
>>>      
>>>
>>That should be covered, shouldn't it? I never really checked the Java
>>    
>>
>
>I mean this more like this:
>
>- extract the documentation files from the project directory (this done by
>  ANT)
>- maybe generate a 'web version' out of this (this is done by XWeb)
>The documentation itself is plain text for the older projects, and XML for
>the newer ones (and sometimes its LaTeX).
>  
>
Ok.

>>> - determine which files have been changed since the last run
>>>      
>>>
>>Does Ant give support for that?
>>    
>>
>
>No, not really. What I really want (and hopefully will write in the next
>time) is a 3-way-diff:
>- one source directory (with the generated web site)
>- one compare directory (which contains an exact copy of the web site on the
>  web server)
>- a target directory, containing all changed data
>This way I can always determine which files I need to copy to the web
>server, w/o downloading all files everytime for comparision.
>  
>
It is probably not too hard to write such an Ant task. Actually it 
probably wouldn't be a task but a new way to define filesets -- I don't 
know if Ant supports extending that without hacking Ant itself.

>>I wonder if an Ant task for XWeb could return a <fileset> with the
>>changes.
>>    
>>
>
>I would do this as an external task. Otherwise XWeb needs to know exactly
>all the time about the content of the target web site.
>  
>
I was thinking about comparing the sourceDir with the targetDir, nothing 
more. If a timestamped version of the structure DOM is in the target 
dir, this structure could be compared to the new one.

>>> - optionally: delete old file from the website
>>>      
>>>
>>That's a tricky one. I wonder how much garbage due to renaming I have
>>created in my webspaces by now. Sometimes I do a big cleanup.
>>    
>>
>
>Tha task mentioned above would also generate a "delete list" (e.g. a shell
>script or ANT project file) containing all files to be deleted, so it can
>be done automtically.
>  
>
That hints at the other problem: do you really want it automatically. 
But I guess, sometimes you do and most likely the target site should be 
XWeb only anyway -- mixing generated content with manual content is 
rarely a good idea.

  Peter

[Xweb-developers] Re:Reactivating development

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

Monday, November 10, 2003, 1:31:13 PM, you wrote:

> [redirected back to list, fully quoted]

Sometimes I forget to do a 'reply to all' :(

> The point I want to make is that Ant is a developers tool and that the

ACK. But building a web site _is_ development (its also programming in so=
me
kind), so why not using developer tools?

> XWeb integration needed in this context seems to be only the XWeb task=20
> for Ant. The frontend I imagine would be more for someone setting up a=20
> small website without many IT skills -- I suspect Webbuilder has a=20
> different target audience, also I think that audience is hard to target=
=20
> with a GUI.

A real good GUI fore XWeb would also handle some parts of Ant scripting
(e.g. for CVS or FTP access).

> Just look at how many people still code Java with vi or=20
> Emacs ;-) I never used much in terms of IDEs for C++, but with Java and=
=20
> Refactoring it is a bit different.

[OT]
Only in my early days I coded w/o a IDE. just because on the Commodores
these days they weren't this much...
But today the lack of a good IDE is a real problem for learing a new
language - such a thing can decide about being productive with a language
or not...

>>- I want to call a _single_ program/script, which should do everything:
>>  - generate project documentation in XML
> That should be covered, shouldn't it? I never really checked the Java

I mean this more like this:

- extract the documentation files from the project directory (this done b=
y
  ANT)
- maybe generate a 'web version' out of this (this is done by XWeb)
The documentation itself is plain text for the older projects, and XML fo=
r
the newer ones (and sometimes its LaTeX).

>>  - determine which files have been changed since the last run
> Does Ant give support for that?

No, not really. What I really want (and hopefully will write in the next
time) is a 3-way-diff:
- one source directory (with the generated web site)
- one compare directory (which contains an exact copy of the web site on =
the
  web server)
- a target directory, containing all changed data
This way I can always determine which files I need to copy to the web
server, w/o downloading all files everytime for comparision.

> I wonder if an Ant task for XWeb could return a <fileset> with the
> changes.

I would do this as an external task. Otherwise XWeb needs to know exactly
all the time about the content of the target web site.

>>  - optionally: delete old file from the website
> That's a tricky one. I wonder how much garbage due to renaming I have
> created in my webspaces by now. Sometimes I do a big cleanup.

Tha task mentioned above would also generate a "delete list" (e.g. a shel=
l
script or ANT project file) containing all files to be deleted, so it can
be done automtically.

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] Re: Reactivating development

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

[redirected back to list, fully quoted]

Hendrik Lipka wrote:

>Monday, November 10, 2003, 3:38:01 AM, you wrote:
>
>  
>
>>What was the reason not to go with an InfoBus? I am currently trying to
>>understand the Bean world and I wonder if I should use some of the ideas 
>>in XWeb itself.
>>    
>>
>
>I think InfoBus is a little bit too complicated. Most projects need only an
>easy way to distribute events about changes / actions to multiple
>components w/o knowing each of them. Jst look at the InfoBus spec
>(http://java.sun.com/products/javabeans/infobus/spec12/IB12Spec.htm):
>it is only about data exchange between components, and IMHO it gives too
>much overhead:
>Step 1. Membership - establishing InfoBus participation
>Step 2. Listening for InfoBus events
>Step 3. Rendezvous on the data to be exchanged
>Step 4. Navigation of structured data
>Step 5. Retrieval of an encoding of the data value
>Step 6. Optional: changing data
>
>Thats why most projects write their own bus system (I have even done this
>by myself :)
>  
>
So I have not to be too embarrassed to write my own publish-subscribe 
system in form of an EventBroker :-) Any comments on the BeanContexts?

>>I don't see that as compelling, a little UNIX script would do the same.
>>    
>>
>
>Yes, you can do many things with a shell script - as long as you run on
>Unix. But FTPing something to a website is npot a thing I want to do in a
>shell script...
>
>  
>
>>Of course being able to call XWeb from Ant is nice to create 
>>cross-platform solutions, but I don't see the need for a further 
>>integration.
>>    
>>
>
>The reasons to go with ANT is:
>- its cross-platform
>- it has _many_ tasks, all in one place
>- powerful file/directory tasks (you can even rename files during file
>  operations)
>- possibility to call many external tools
>  
>
I don't mind integrating XWeb into Ant to a certain degree, I think that 
is defintely a good idea -- I use Ant for pretty much all my projects. 
And I agree that it is a quite powerful tool -- also I wouldn't say it 
is better than a shell, it is too close in its idea to a shell 
script/makefile. But the cross-platform thing is definitely a plus. I 
love having only one set of build instructions :-) And not everyone 
running Windows runs Cygwin as they should ;-)

The point I want to make is that Ant is a developers tool and that the 
XWeb integration needed in this context seems to be only the XWeb task 
for Ant. The frontend I imagine would be more for someone setting up a 
small website without many IT skills -- I suspect Webbuilder has a 
different target audience, also I think that audience is hard to target 
with a GUI. Just look at how many people still code Java with vi or 
Emacs ;-) I never used much in terms of IDEs for C++, but with Java and 
Refactoring it is a bit different.

>>The Ant task as you described -- just called the main 
>>process from within Ant, seems quite appropriate. Maybe some extra 
>>options like configuring the baseURL or some parameters might be helpful.
>>    
>>
>
>Yes, something like that would help. My idea how to build my website is:
>- I want to call a _single_ program/script, which should do everything:
>  - generate project documentation in XML
>  
>
That should be covered, shouldn't it? I never really checked the Java 
range of documentation generation since I sticked with basic JavaDoc so 
far, but I imagine there is something XMLish. I know that Doxygen 
supports XML export, but that is of course not Java.

>  - copy this in to the website source
>  - run XWeb
>  - determine which files have been changed since the last run
>  
>
Does Ant give support for that? I wonder if an Ant task for XWeb could 
return a <fileset> with the changes. Or is it possible to turn URL lists 
into <fileset>s?

>  - transfer this changed file to the website
>  - optionally: delete old file from the website
>  
>
That's a tricky one. I wonder how much garbage due to renaming I have 
created in my webspaces by now. Sometimes I do a big cleanup.

>Most of this could be done from ANT, and makes not _that_ much sense in
>XWeb. Maybe others have different needs...
>  
>
I'd like to see some of the update management in XWeb. At the moment my 
thinking goes towards:
- adding time stamps into the makefile DOM during processing,
- copy a full version of the DOM, including all the extra bits like 
images created and these timestamps into the output
- use this for diffs and in combination with dependency analysis for 
incremental updates, it would also provide the information which files 
are gone and could be deleted

The first bit has the nice extra effect that it could provide 
stylesheets with a "last updated on..." opportunity.

The XWeb frontend should definitely have some upload capacities. As said 
before: I see a completely different target audience for that.

   Peter

Re: [Xweb-developers] Reactivating development

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

murphee (Werner Schuster) wrote:

> Peter Becker wrote:
> murphee wrote:
>
>>> http://www.angelfire.com/co/werners/developerzone/webbuilder.html
>>
>> Yes, that was one of the more advanced tries. And there was the 
>> Mozilla plugin and my own attempt.
>> Your bus described in the presentation -- is that a Bean InfoBus?
>
>
> Nope, but it was influenced by it InfoBus (and jEdits EditBus);
> Webbuilder was designed to be very extensible and something like
> that was necessary for that;

What was the reason not to go with an InfoBus? I am currently trying to
understand the Bean world and I wonder if I should use some of the ideas
in XWeb itself.

>>> the Xweb tree and also manipulate the build process (which is
>>> realized with Ant);
>>
>> What exactly does Ant do in this? The deployment/upload bit is 
>> obvious, but I am not sure what else Ant could do. But that might be 
>> my lack of imagination :-)
>
>
> Well, basically Xweb is thought of as a compiler that compiles websites
> and Ant is used for the build process that does everything else;
> preprocessing could involve... eg. updating the input files before
> generating the websites; like updating the input files from a CVS
>  (the build file could be run by some cron job or be triggered by
> CVS commits,...);

> Another idea (useful for OpenSource projects) would be generating
> Javadoc (or some other doc) and copying it into the finished website
>  (for example at the JOGI Project (referenced in my sig) I put the
> Javadoc for the API online; but I always have to generate it
> and copy it to the output dir manually);
> Generally updating input files, like regenerating them from DB
>  sources, ...

I don't see that as compelling, a little UNIX script would do the same.
Of course being able to call XWeb from Ant is nice to create
cross-platform solutions, but I don't see the need for a further
integration. The Ant task as you described -- just called the main
process from within Ant, seems quite appropriate. Maybe some extra
options like configuring the baseURL or some parameters might be helpful.

> Oh yeah... running JTidy before Xweb would be useful, if you want
> to import non-XHTML input files (this would make XWeb more userfriendly,
> as the user does not have to bother with converting their HTML files
> to valid XHTML);

I defintely want JTidy support within XWeb, it seems to be too important
to need extra tools. The XHTML requirement for things like the generic
stylesheet coming with the distribution is a bit of a drawback.

> etc. etc. ...
>
>
>>> Webbuilder is only a prototype, but if there is interest in the thing,
>>> I could put it on Sourceforge and do some work on it again;
>>
>> I'd rather like to see it as a part of XWeb -- the masterplan has 
>> always been to replace NetObjects Fusion :-)
>
>
> hmm... Netobjects Fusion... is that still on the market? 

Google finds it: http://www.netobjects.com/ -- if only they would know
how to do a proper website :-) The version 7.5 is a bit higher than the
one I used years ago (3.0).

> Haven't heard
> much about it lately; lets aim for... er.. the Macromedia thing now...
> Dreamweaver or something.......

Yeah, Dreamweaver seems to be the one used at the moment. Never tried it
myself.

>
> >  And I don't see enough resources
>
>> to run multiple frontends, but who knows -- sometimes people pop up 
>> out of a sudden. I'm easy -- if you want your own project that's 
>> fine, too. It just seems better for pulicity purposes to have just one.
>
>
> Hmm... well, lets see, what happens to the other Frontend project;
>
> I don't really have much time (make that: no time) for updating
> Webbuilder (although I've been planning to); I could set up the
> project on Sourceforge and give you (and possibly others CVS access
> to it)... or something like that; anything's better than leaving
> the code to rot (a lot of work in there);

I'm happy to put it into the XWeb CVS. I think that gives the code more
chance to be found than yet another SF project without any activity. But
it's your choice of course. And there is the licensing issue, at the
moment XWeb is still public domain. The thing with licenses is that I
don't really want to care, but sometimes I feel I should :-)

>
>> Input: two absolute paths, one the current position, one the target
>> 1) strip both target and source of the common start
>> 2) add ".." + File.separator n-times in front of the target, where n 
>> is the number of File.separators in the source
>
>
> that should work, I guess;
>
>> Similarly and safer you could do that with File.getParent(), dump all 
>> parents on a stack, find the deepest common parent, then add ".."s 
>> when going down the source side and afterwards the directory names 
>> when going down the target side.
>
>
> well, I tried to fix the bug some time ago... I think I changed the code
> that generates the structure tree (that is copied into each XML file);
> instead of adding the base url to each link, I prepended "../" to the
> string for each new level (ie. the code works recursively, and I added
> the "../" each time the code went down another recursion level
>  (= section); that should work, but it didn't really... hell knows
> why; after some hours I got distracted and... well, I guess the code
> still lies hidden somewhere;

Part of the problem is that you don't really know what is in the
@targetDir attributes -- it can be no directory change or multiple. The
files themself do allow changing directories, too -- there is nothing
enforcing the target location to be in the current directory. I often
use this to hack the main page -- the overview page of the first section
is sometimes "../index.html" in my sites. I think there were some other
issues why relative URLs aren't that easy. But comparing the actual
File-s should be safe if done right.

  Peter

Re: [Xweb-developers] Reactivating development

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

murphee (Werner Schuster) wrote:

> Peter Becker wrote:
> murphee wrote:
>
>>> http://www.angelfire.com/co/werners/developerzone/webbuilder.html
>>
>> Yes, that was one of the more advanced tries. And there was the 
>> Mozilla plugin and my own attempt.
>> Your bus described in the presentation -- is that a Bean InfoBus?
>
>
> Nope, but it was influenced by it InfoBus (and jEdits EditBus);
> Webbuilder was designed to be very extensible and something like
> that was necessary for that;

What was the reason not to go with an InfoBus? I am currently trying to 
understand the Bean world and I wonder if I should use some of the ideas 
in XWeb itself.

>>> the Xweb tree and also manipulate the build process (which is
>>> realized with Ant);
>>
>> What exactly does Ant do in this? The deployment/upload bit is 
>> obvious, but I am not sure what else Ant could do. But that might be 
>> my lack of imagination :-)
>
>
> Well, basically Xweb is thought of as a compiler that compiles websites
> and Ant is used for the build process that does everything else;
> preprocessing could involve... eg. updating the input files before
> generating the websites; like updating the input files from a CVS
>  (the build file could be run by some cron job or be triggered by
> CVS commits,...);

> Another idea (useful for OpenSource projects) would be generating
> Javadoc (or some other doc) and copying it into the finished website
>  (for example at the JOGI Project (referenced in my sig) I put the
> Javadoc for the API online; but I always have to generate it
> and copy it to the output dir manually);
> Generally updating input files, like regenerating them from DB
>  sources, ...

I don't see that as compelling, a little UNIX script would do the same. 
Of course being able to call XWeb from Ant is nice to create 
cross-platform solutions, but I don't see the need for a further 
integration. The Ant task as you described -- just called the main 
process from within Ant, seems quite appropriate. Maybe some extra 
options like configuring the baseURL or some parameters might be helpful.

> Oh yeah... running JTidy before Xweb would be useful, if you want
> to import non-XHTML input files (this would make XWeb more userfriendly,
> as the user does not have to bother with converting their HTML files
> to valid XHTML);

I defintely want JTidy support within XWeb, it seems to be too important 
to need extra tools. The XHTML requirement for things like the generic 
stylesheet coming with the distribution is a bit of a drawback.

> etc. etc. ...
>
>
>>> Webbuilder is only a prototype, but if there is interest in the thing,
>>> I could put it on Sourceforge and do some work on it again;
>>
>> I'd rather like to see it as a part of XWeb -- the masterplan has 
>> always been to replace NetObjects Fusion :-)
>
>
> hmm... Netobjects Fusion... is that still on the market? 

Google finds it: http://www.netobjects.com/ -- if only they would know 
how to do a proper website :-) The version 7.5 is a bit higher than the 
one I used years ago (3.0).

> Haven't heard
> much about it lately; lets aim for... er.. the Macromedia thing now...
> Dreamweaver or something.......

Yeah, Dreamweaver seems to be the one used at the moment. Never tried it 
myself.

>
> >  And I don't see enough resources
>
>> to run multiple frontends, but who knows -- sometimes people pop up 
>> out of a sudden. I'm easy -- if you want your own project that's 
>> fine, too. It just seems better for pulicity purposes to have just one.
>
>
> Hmm... well, lets see, what happens to the other Frontend project;
>
> I don't really have much time (make that: no time) for updating
> Webbuilder (although I've been planning to); I could set up the
> project on Sourceforge and give you (and possibly others CVS access
> to it)... or something like that; anything's better than leaving
> the code to rot (a lot of work in there);

I'm happy to put it into the XWeb CVS. I think that gives the code more 
chance to be found than yet another SF project without any activity. But 
it's your choice of course. And there is the licensing issue, at the 
moment XWeb is still public domain. The thing with licenses is that I 
don't really want to care, but sometimes I feel I should :-)

>
>> Input: two absolute paths, one the current position, one the target
>> 1) strip both target and source of the common start
>> 2) add ".." + File.separator n-times in front of the target, where n 
>> is the number of File.separators in the source
>
>
> that should work, I guess;
>
>> Similarly and safer you could do that with File.getParent(), dump all 
>> parents on a stack, find the deepest common parent, then add ".."s 
>> when going down the source side and afterwards the directory names 
>> when going down the target side.
>
>
> well, I tried to fix the bug some time ago... I think I changed the code
> that generates the structure tree (that is copied into each XML file);
> instead of adding the base url to each link, I prepended "../" to the
> string for each new level (ie. the code works recursively, and I added
> the "../" each time the code went down another recursion level
>  (= section); that should work, but it didn't really... hell knows
> why; after some hours I got distracted and... well, I guess the code
> still lies hidden somewhere;

Part of the problem is that you don't really know what is in the 
@targetDir attributes -- it can be no directory change or multiple. The 
files themself do allow changing directories, too -- there is nothing 
enforcing the target location to be in the current directory. I often 
use this to hack the main page -- the overview page of the first section 
is sometimes "../index.html" in my sites. I think there were some other 
issues why relative URLs aren't that easy. But comparing the actual 
File-s should be safe if done right.

  Peter

Re: [Xweb-developers] Reactivating development

[murphee (W. Schuster) <wer...@ne...>]

Peter Becker wrote:
murphee wrote:
>> http://www.angelfire.com/co/werners/developerzone/webbuilder.html
> Yes, that was one of the more advanced tries. And there was the Mozilla 
> plugin and my own attempt.
> Your bus described in the presentation -- is that a Bean InfoBus?

Nope, but it was influenced by it InfoBus (and jEdits EditBus);
Webbuilder was designed to be very extensible and something like
that was necessary for that;


>> the Xweb tree and also manipulate the build process (which is
>> realized with Ant);
> What exactly does Ant do in this? The deployment/upload bit is obvious, 
> but I am not sure what else Ant could do. But that might be my lack of 
> imagination :-)

Well, basically Xweb is thought of as a compiler that compiles websites
and Ant is used for the build process that does everything else;
preprocessing could involve... eg. updating the input files before
generating the websites; like updating the input files from a CVS
  (the build file could be run by some cron job or be triggered by
CVS commits,...);
Another idea (useful for OpenSource projects) would be generating
Javadoc (or some other doc) and copying it into the finished website
  (for example at the JOGI Project (referenced in my sig) I put the
Javadoc for the API online; but I always have to generate it
and copy it to the output dir manually);
Generally updating input files, like regenerating them from DB
  sources, ...
Oh yeah... running JTidy before Xweb would be useful, if you want
to import non-XHTML input files (this would make XWeb more userfriendly,
as the user does not have to bother with converting their HTML files
to valid XHTML);
etc. etc. ...


>> Webbuilder is only a prototype, but if there is interest in the thing,
>> I could put it on Sourceforge and do some work on it again;
> I'd rather like to see it as a part of XWeb -- the masterplan has always 
> been to replace NetObjects Fusion :-)

hmm... Netobjects Fusion... is that still on the market? Haven't heard
much about it lately; lets aim for... er.. the Macromedia thing now...
Dreamweaver or something.......


 >  And I don't see enough resources
> to run multiple frontends, but who knows -- sometimes people pop up out 
> of a sudden. I'm easy -- if you want your own project that's fine, too. 
> It just seems better for pulicity purposes to have just one.

Hmm... well, lets see, what happens to the other Frontend project;

I don't really have much time (make that: no time) for updating
Webbuilder (although I've been planning to); I could set up the
project on Sourceforge and give you (and possibly others CVS access
to it)... or something like that; anything's better than leaving
the code to rot (a lot of work in there);


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

that should work, I guess;

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

well, I tried to fix the bug some time ago... I think I changed the code
that generates the structure tree (that is copied into each XML file);
instead of adding the base url to each link, I prepended "../" to the
string for each new level (ie. the code works recursively, and I added
the "../" each time the code went down another recursion level
  (= section); that should work, but it didn't really... hell knows
why; after some hours I got distracted and... well, I guess the code
still lies hidden somewhere;


murphee
-- 
Werner Schuster (murphee)
Student of SoftwareEngineering and KnowledgeManagement
Maintainer of the OGO-JOGI Project @ http://ogo-jogi.sourceforge.net/

[Xweb-developers] Re: Changes to XWeb

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

Hendrik Lipka wrote:

>Thursday, November 6, 2003, 11:33:28 AM, you wrote:
>
>  
>
>>syntax. I was thinking about using Ant-style syntax in some other spots
>>later on, i.e. the "$10" would be "{$10}" instead.
>>    
>>
>
>In this case, it would be nice to have it done properly and to introduce
>named replacement, to be able to insert any value into a filename...
>  
>
Were would the other values come from?

One thing I was thinking of is introducing parameters for the 
documentStyles -- if you look at this site section as an example: 
http://www.kvocentral.org/publications/index.html -- each year is 
created from the same input file using the same stylesheet with just a 
different parameter "year", which filters publications out of the input 
file (BibTeXML). For each page I need a different documentStyle at the 
moment, since there is not way to attach a parameter to the entries. At 
the moment there are a bunch of definitions like this:

        <documentStyle type="XMLPublications2003">
            <xsl stylesheet="layout/generic.xsl" navigationElement="html">
                <parameter name="nav.main.pos" value="left"/>
                <parameter name="nav.sec.pos" value="nested"/>
                <parameter name="nav.sec.visible" value="current"/>
                <parameter name="nav.sec.firstEntry" value="section"/>
                <parameter name="style.markup.firstLetter" value="on"/>
                <parameter name="style.markup.linkTypes" value="on"/>
                <parameter name="feature.include.footer" 
value="footer.xml"/>
                <parameter name="feature.internalLink.token" value="!"/>
                <xsl stylesheet="layout/publications.xsl">
                    <parameter name="year" value="2003"/>
                    <xsl stylesheet="layout/replaceAuthors.xslt"/>
                </xsl>
            </xsl>
        </documentStyle>

Good thing I don't change much in there and the copy and paste happens 
only once a year, but it is definitely not the way I'd like to do it. 
The first thing I'd like to change is the option to set a 
property/parameter/variable as child of an <entry>, so the innermost 
<parameter> of the <xsl> would be:

                    <parameter name="year" value="{$year}"/>

The other bit that's missing is reuse of tasks, in this case the layout 
part is the same for most types on the site (apart from copying and the 
BibTeX creation). Instead of giving the parameters for the layout every 
time (and changing it everywhere if needed), I'd like to call other 
tasks. The syntax I think of would be serial, not nested and I think of 
introducing <task> as an element. A <documentStyle> would then define 
the images to be rendered plus a task to call. Tasks can call each other 
to allow maximum reuse.

[..log4j descriptions...]

Ok, it does sound quite handy and slightly better than util.logging. 
Here are the main differences I have figured out so far -- + is for 
log4j, - is for util.logging:
+ no search for the right logging.preferences. With util.logging you 
have to either edit the file in the libs dir of the JVM you are 
currently using or give some command line property to point to another 
configuration. Not what I want my users to do, I'd like to send them a 
file and say: put this in that dir and send me the file called XYZ after 
you ran the program
- syntax is simpler in util.logging. Properties format seems good 
enough, XML overkill.
+ more available outputs
- download size
+ works with older JDKs/JVMs

Not much difference as far as I can tell, but maybe it is not too bad an 
idea if I just try it and check the details. The move to 1.4 could be 
postponed for a while.

>>Do you have a pointer to a good log4j tutorial? Otherwise I can google
>>for one.
>>    
>>
>
>Starting here is a good idea:
>http://jakarta.apache.org/log4j/docs/documentation.html
>The short manual, and the JavaDoc  are a good start. Additionaly,
>http://supportweb.cs.bham.ac.uk/documentation/tutorials/docsystem/build/tutorials/log4j/log4j.html
>makes a good read.
>
>You can also ask me for examples - I will the go and look for some of my
>code parts...
>  
>
Ok, I'll read some of that and then just try.

>>Yeah -- maybe I should just go with the regex things for now since that
>>fits neatly in there, if people can't handle it but want to do something 
>>similar, we can always add easier options later.
>>    
>>
>
>I think many users will be happy with specifying order explicitly, as
>normally you won't have this much entries in the navigation. In most cases,
>only such directories as images or downloads contains too mucn entries to
>use a 'copy many files' tasks...
>  
>
But the number scheme would give me a nice feeling of being back to 
Basic V2 again :-)

I'll leave the <entryset> option with the usual regex replacement 
abilites, but no extra options for the order for now -- let's see how 
people use it. That's always the fun part -- I am quite astonished what 
people made with XWeb so far. It was originally written for my sites, 
then I published it and did the smart move of writing a manual, so now I 
get emails from people I don't know every fortnight or so :-)

  Peter

Re: [Xweb-developers] Reactivating development

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

murphee (Werner Schuster) wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Peter

Re: [Xweb-developers] Reactivating development

[murphee (W. Schuster) <wer...@ne...>]

Peter Becker wrote:

Hey, great to see some action in the Xweb project again;


> Other things I'd like to see:
> - globbing and regexp for <entryset>s and <fileset>s -- that should 
> match things like "*.xml" to "*.html" conversions

thats great; I suppose it would be possible to bulk-copy whole 
directories of files instead of having to copy them individually;


> - support for more operations, e.g. JTidy and FOP, maybe Freemarker 
> (http://freemarker.sourceforge.net/) or (rather later) things similar to 
> this: http://www.mullassery.com/software/ANT/index.jsp or this: 
> http://www.oopsconsultancy.com/software/xmltask.html -- I wonder if 
> integrating Ant tasks in general would be hard.

Well, how about making more use of Ant for XWeb; mostly for dependancy
checking; maybe split up the processing model upon several Ant tasks
that can then be used;




> - a large refactoring towards a process-oriented model with at least two 
> iterations through the chains (prepare, do)

Some dependancy checking would be great; mostly to allow incremental
builds instead of the monolithic full rebuilds each time;


> Jon wants to have a go at the frontend bit, at least some tree 
> manipulations with a text editor pane, 

There is also my 2 year old (currently not active) project called
Webbuilder, basically a GUI for XWeb. At
http://www.angelfire.com/co/werners/developerzone/webbuilder.html
you can get the tar.gz and some overview of the structure;
Its about 2 years old, so I suppose the code is not uptodate.
But it can manipulate Xweb files (as far as I remember);


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

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

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


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

murphee
-- 
Werner Schuster (murphee)
Student of SoftwareEngineering and KnowledgeManagement
Maintainer of the OGO-JOGI Project @ http://ogo-jogi.sourceforge.net/

[Xweb-developers] Re:Changes to XWeb

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

Thursday, November 6, 2003, 10:18:03 AM, you wrote:

>      for (int j =3D 1; j <=3D matcher.groupCount(); j++) {
>           targetName =3D targetName.replaceAll("\\$"+ String.valueOf(j)=
,=20
> matcher.group(j));
>      }

Hmm. Better do it backwards, otherwise $10 and $1 would get mixed (I'm no=
t
sure how to specify a '0' after a '$1', though...)

> Maybe at the moment, but I think the "official" API might take over qui=
ckly.

Don't think so. log4j is _really_ widespread. All larger projects I know
are using it (sometimes hidden behind an own logging layer to make easy
replacement possible).

> How do you configure log4j?

Depends: if I have a XML config file already there for the application, t=
he
log4j config is just part of it (using a <log4j:configuration>
element). If not, I just specify a properties file containing the
configuration. In the most simple cases, I configure everything
programatically.

> The plain and XML output the JDK produces seems good enough for me -- I
> don't see why we need to log into a database or an IM network in XWeb.=20

Think about someone integrating XWeb into a larger application - maybe th=
ey
need such a thing. And if someone runs XWeb via a cron job, IM or mail
notification would be handy...
Log4j also allows for very flexible output formatting (on the screen, kee=
p
everything short, but be verbose in the debug log). I also like the
'appender additivity' - the debug log should contain all application log
messages, but not vice versa.

> And I don't think that would be hard to do with the JDK logging=20
> framework. I'd actually write a custom one anyway since I want to log=20
> into a frontend with output that allows interaction.

I try to never re-invent the whell...

> What exactly do the 345kb give me in comparison to util.logging? Don't
> get we wrong -- I don't say log4j is not an option at all, I just want=20
> to know what it gives me, since I don't know much about it.

- it does not force me to JDK 1.4
- it is complete
- appender additivity
- flexible output formatting
- flexbile configuration
- widely used, and very stable
- many tools and enhancement available
- the de-facto standard for logging

I think I could live with the java.util.logging, as long as it allows for=
 a
flexible logging scheme and easy configuration.

>                 if (!"regex".equals(child.getAttributeValue("mode"))) {
>                     // @todo we probably need more escaped here
>                     sourceFilesAttrib =3D=20
> sourceFilesAttrib.replaceAll("\\.", "\\.");
>                     sourceFilesAttrib =3D=20
> sourceFilesAttrib.replaceAll("\\*", "(.*)");
>                     sourceFilesAttrib =3D=20
> sourceFilesAttrib.replaceAll("\\?", "(.)");
>                 }

> I have to add the other regexp special characters for the escapes.

Maybe you can look into the ORO class transforming the glob into a regula=
r
expression... As I said - why re-invent the wheel? It is hard to do it
right, and easy to make the same mistakes again...

> Are there any good ideas around how to determine order for the
> corresponding <entryset>s? I want to do something like this:

>   <entryset sourceFiles=3D"*.xhtml" targetFiles=3D"$1.html" names=3D"$1=
"=20
> ids=3D"$1" type=3D"XHTML"/>

> Which should fill up a whole section with XHTML documents, using the=20
> file names as part of the navigation. In that case order is somehow=20
> relevant, and it is neither alphabetical nor chronological.

I would skip this feature. If a users wants a specifiy order, he should
specify it explicitly.
Maybe your regex solution could be optional, but only for advanced users.

Another idea: add a 'order' attribut, like:

<entryset mode=3D"transform" order=3D"number" sourceFiles=3D"*.xhtml"
 targetFiles=3D"*.html" names=3D"*" ids=3D"*" type=3D"XHTML"/>
=20
where the 'order' attribute specifies how to determine the navigation
order. It could map to plugin-classes / predefined classes.

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

Re: [Xweb-developers] Re:Changes to XWeb

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

Hendrik Lipka wrote:

>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.
>  
>
I just finished the 1.4 version -- but it wouldn't be hard to change at 
all, at the moment it is more about getting things going. I did the $n 
replacements manually, but it is just this bit:

     for (int j = 1; j <= matcher.groupCount(); j++) {
          targetName = targetName.replaceAll("\\$"+ String.valueOf(j), 
matcher.group(j));
     }

Not too hard at all :-)

>>>>- 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. 
>
Maybe at the moment, but I think the "official" API might take over quickly.

>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 for
>debugging [structured by the Java classes]. Its really simple to do). 
>
How do you configure log4j? I have mixed feelings about the JDK 
approach: on one hand you can configure it externally and in extreme 
detail, which means you can turn specific logging parts on on a client 
machine. On the other hand the logging.properties file is not the best 
place to fiddle around with (once you found the right one) and giving 
specific logging options via command line is a bit painful.

>It
>got a lot of tools (just have alook at the supported Appenders...).
>
The plain and XML output the JDK produces seems good enough for me -- I 
don't see why we need to log into a database or an IM network in XWeb. 
And I don't think that would be hard to do with the JDK logging 
framework. I'd actually write a custom one anyway since I want to log 
into a frontend with output that allows interaction.

>And it
>supports Java since 1.2, too. Commons Logging and the util.logging from 1.4
>are just inferior.
>  
>
What exactly do the 345kb give me in comparison to util.logging? Don't 
get we wrong -- I don't say log4j is not an option at all, I just want 
to know what it gives me, since I don't know much about it.

>>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).
>>    
>>
>
>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)
>  
>
JAI is even more evil than JIMI :-) Why the heck do you want to reduce 
an OO environment down to a command line interface as done there 
(http://java.sun.com/products/java-media/jai/forDevelopers/jai-apidocs/index.html)?

javax.imageio is the most sensible API from the three I tried (imageio, 
JAI, JIMI).

>>>You are really optimistic :) My first test case would be something like
>>>source='??some*.?htm?' target='$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 there
>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 are
>regular chars in a glob expression, one cannot specifiy them for the
>substitution... Possible solution: find all '.' and '*' expressions in the
>glob expression, and suround them with () in the generated RegEx.
>  
>
Currently it looks like this:

                if (!"regex".equals(child.getAttributeValue("mode"))) {
                    // @todo we probably need more escaped here
                    sourceFilesAttrib = 
sourceFilesAttrib.replaceAll("\\.", "\\.");
                    sourceFilesAttrib = 
sourceFilesAttrib.replaceAll("\\*", "(.*)");
                    sourceFilesAttrib = 
sourceFilesAttrib.replaceAll("\\?", "(.)");
                }

I have to add the other regexp special characters for the escapes.

>>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 
>>but don't know much about RegExp. Forgetting to escape the dot would be 
>>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 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 
>>    
>>
>
>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 would
>solve this?
>  
>
The problem is that this gets resolved in the stylesheet. I added some 
checking into the latest versions I used. I think they never made it 
back into XWeb -- I'll check that and add them if necessary. But the 
only way I found to give feedback is to put stuff on stdout via 
xsl:message -- which gets lost in XWeb's verbosity. I think the problem 
can only be fixed by a better reporting in general. One idea would be to 
collect all stdout from the stylesheets (if possible) and to enlist it 
in the end independent from the rest of the feedback. Another idea would 
be reducing the verbosity of XWeb itself.

>>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.
>>    
>>
>
>Thats what I was thinking anyway...
>  
>
Haven't done that bit yet, will add it now. I got this far:

 <fileset sourceFiles="*.png" type="copy"/>
 <fileset sourceFiles="*.png" targetFiles="$1_th.png" type="thumbnail"/>

Which copies a bunch of images and generates a set of thumbnails. My 
example application is a gallery section for an XWeb site, where I want 
to be able to drop in an PNG or an SVG and get it added to a thumbnail 
page as well as copied across.

Note that I also reduce the need for attributes -- the @targetFile(s) is 
now optional everywhere, it defaults to the file name of the source(s).

Are there any good ideas around how to determine order for the 
corresponding <entryset>s? I want to do something like this:

  <entryset sourceFiles="*.xhtml" targetFiles="$1.html" names="$1" 
ids="$1" type="XHTML"/>

Which should fill up a whole section with XHTML documents, using the 
file names as part of the navigation. In that case order is somehow 
relevant, and it is neither alphabetical nor chronological. One idea I 
had was going alphabetical and then using this instead:

  <entryset mode="regex" sourceFiles="(\d*)(\D.*).xhtml" 
targetFiles="$2.html" names="$2" ids="$2" type="XHTML"/>

Which should work, but the syntax is not really obivous unless someone 
knows regex quite well. The input files would then have to have 
preceeding numbers indicating their order. Alternatively this could be used:

  <entryset mode="regex" sourceFiles="(.)(.*).xhtml" 
targetFiles="$2.html" names="$2" ids="$2" type="XHTML"/>

Which is the same trick with a single leading character to indicate 
order. Another variant would be a prefix separated by some character, e.g.:

  <entryset mode="regex" sourceFiles="([^ ]) (.*).xhtml" 
targetFiles="$2.html" names="$2" ids="$2" type="XHTML"/>

Any other ideas? Any ideas how to make that approach more accessible, 
i.e. to get the same without the regexs? I don't really mind naming the 
files in a certain scheme, but judging from the user feedback many find 
the environment variables a killer, so I don't want to come up with 
redular expressions :-)

   Peter