Thread: [Xweb-developers] Reactivating development
Brought to you by:
peterbecker
Menu
▾
▴
xweb-developers
|
From: Peter B. <pe...@pe...> - 2003-11-05 21:40:43
|
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 |
|
From: murphee (W. Schuster) <wer...@ne...> - 2003-11-06 11:29:29
|
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/ |
|
From: Peter B. <pe...@pe...> - 2003-11-06 12:43:10
|
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
|
|
From: murphee (W. Schuster) <wer...@ne...> - 2003-11-08 09:15:36
|
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/ |
|
From: Peter B. <pe...@pe...> - 2003-11-10 02:42:09
|
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 |
|
From: Peter B. <pe...@pe...> - 2003-11-10 12:35:16
|
[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 |
|
From: Hendrik L. <hen...@gm...> - 2003-11-10 12:52:51
|
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 |
|
From: murphee (W. Schuster) <wer...@ne...> - 2003-11-12 01:26:43
|
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/ |
|
From: Peter B. <pe...@pe...> - 2003-11-12 06:44:56
|
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 |
|
From: Peter B. <pe...@pe...> - 2003-11-10 05:16:55
|
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 |
|
From: murphee (W. Schuster) <wer...@ne...> - 2003-11-12 01:04:09
|
>> 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/ |
|
From: Peter B. <pe...@pe...> - 2003-11-12 07:01:54
|
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 |
|
From: Peter B. <pe...@pe...> - 2003-11-10 23:31:02
|
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 |
|
From: Hendrik L. <hen...@gm...> - 2003-11-11 08:39:00
|
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 |
Thanks for helping keep SourceForge clean.
X