You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/04/15 01:19:59 UTC
[FYI] www.ormaz.it usecase
Today I went online with my latest creation http://www.ormaz.it which is
entirely based on cocoon 2.1-dev compiled today. This says it all about
how confident I am about the code we have in CVS.
I want to tell you how I did it and why I choose it.
The site is very small. The IA diagram [http://www.jjg.net/ia/visvocab/]
lists no more than 10 different pages or decks of pages. Moreover, I've
done *all* the work by myself. Everything, from taking the pictures,
graphic design, CSS/HTML creation, programming, installing.
The result is:
1) no need for actions, everything is performed with 120 lines of
flowscript
2) no business logic in the flowscript: I wrote a few java objects that
implemented a really-poor-man file repository on top of the file system.
3) no use of XSP
4) use of style-clean XHTML for all document markup and velocity as
template system for simple pages
5) no database. all information is stored in xml files in a virtual xml
repository on disk.
6) header/footer are not cincluded by they are 'wrapped' by a
'style.xslt' stylesheet at the end of every pipeline. This concept of
XSLT style wrapping is pretty cool and *much* more powerful than any
server-side-include paradigm.
7) the site contains a complete CMS in the administrative section. user
authentication is done via flowscript, connecting with a very simple
user registry fed with java.properties file. really-poor-man-acl, you
could say.
8) the admin section is heavily DHTML-ized. It works on all 6th
generation browsers and the user is able to upload images and such
without requiring rountripping
[by setting the 'src' property of an img with the value of the <input
type="file"> it is possible to visualize the image the user is uploading
right from disk, without requiring any rountripping. this improves the
user experience *immensively*!]
[also, using dom cloneNode() it is possible to keep on adding images in
the form without requiring roundtripping.]
My experiences in DHTML programming with 6th browsers has been very
positive. IE and Moz are pretty much compatible, there are only a few
issues that really bug me:
1) if you have <div class="blah"> blah is found in div.class in mozilla
but div.className in IE! sometimes I think those guys in redmond just
need more sunshine. I ended up testing for 'document.all' to
discriminate between the two DOM types.
2) the event model is *completely* different. there are tricks to make
the same code work on both, but things like onclick(), onchange() and
onfocus() never seems to work the same way. I ended up using
onpropertychange() which is IE-specific. It is amazing how two different
browsers can claim compliance with a spec, but still be completely not
interoperable.
To be honest, I have to say this is not only Redmond's fault: the DOM
spec lacks any connection with the system. So, it says that events are
pushed, and what is their names, but not *how* and *in what order*!
As a result, I wrote some 300 lines of javascript for the client side
and only 4 of them were browser-dependent.
9) I used Mozilla for development. If you are using another browser to
develop your sites, throw it away and use mozilla. If you haven't done
so, please read:
http://devedge.netscape.com/viewsource/2003/mozilla-webdev/
but even better, go to http://livehttpheaders.mozdev.org and download
that awesome plugin that shows you the dump of all the headers that flow
thru between you and the server. This saved me hours of cocoon-view
based debugging, expecially on multipart forms. Not counting the ease of
use of the javascript console compared to the stinking useless IE error
popup window. yuck.
10) at the end, this is a web site designed with *extreme usability* in
mind. I spent endless hours trying to remove *everything* possible from
the site without sacrificing the information that the site needed to
transmit. Also, the site is completely manageable by people who are
barely able to read email.
11) despite the ability of IE6 on all machines that need to access the
internal CMS, I decided *NOT* to use any contentEditable solution but to
use pure forms for two reasons:
a) their content is always structured
b) web users are used to forms, but not to inline editable pages
(yet, at least). Forms provide visual semantics which are generally
understood, inline editing is not standardized and without proper visual
indications, users assume that if it's not in a textarea, the content is
simply not editable. I think that even in a future of advanced inline
editing, forms will still have their pretty consistent usage because of
the clear visual semantics that are associated to them.
- o -
Lessons learned:
a) cocoon can be very useful for small sites, but the hard part is
*not* to use all its features and get down to easy stuff like a velocity
template that generates XHTML. Still, it can provide very useful
features even in that case (think style wrapping instead of
header/footer inclusion)
b) flowscript rocks the planet. it will rock even more combined with
hot-deployable avalon components.
c) LiveConnect (the glue between javascript and java) makes it hard to
abuse the flow to write business logic in it. Even after a few lines of
having to call the classes by their full package names, you spin it off
into their own classes and call them. This turns out to be very
straightforward and keeps the flow *very* clean.
d) flow + inputmodules + redirection from flow totally substitute the
need for actions in the sitemap. The elegance of the resulting solution
is not even close to be action-based equivalent.
e) sessions and continuations do need to cohexist and they do very well
already.
f) cocoon needs an xml repository as an avalon component accessible
from the flow! the use of protocols is simply not enough for the kind of
data manipulation required in seriously roundtripping webapps that have
to mix, match and change stored xml content. This doesn't need to be an
xml database, it could be a virtual file system on top of a blob-capable
DB or a CVS view.
Hope this helps.
--
Stefano.
Re: [FYI] www.ormaz.it usecase
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/15/03 9:41 AM Bruno Dumon wrote:
> On Tue, 2003-04-15 at 01:19, Stefano Mazzocchi wrote:
>
>
>> 6) header/footer are not cincluded by they are 'wrapped' by a
>>'style.xslt' stylesheet at the end of every pipeline. This concept of
>>XSLT style wrapping is pretty cool and *much* more powerful than any
>>server-side-include paradigm.
>
>
> So if I understand correctly, you're using an XSL that basically
> consists of some static HTML with somewhere a <xsl:copy-of select="/"/>.
More or less yes.
> I'm rather opposed to such constructs, because those XSL's are usually
> quite expensive to execute, while doing mostly nothing.
True.
> If the pages can
> be cached, this is not really a problem, but on a dynamic site this can
> cause big performance degradations.
Again, true. Luckily enough, I didn't have any performance constraints
with this site since it will never get much load.
> The same wrapping behaviour can also be achieved by inversing the way
> you do the cinclude: instead of cincluding the header and footer, let
> the template page that contains the header and footer cinclude the main
> content.
Let me show you a use case:
1) template 1
<html>
<head>
<title>ricambi</title>
<link type="stylesheet" src="styles/ricambi.css"/>
</head>
<body>
...
</body>
</html>
2) resulting page
<html>
<head>
<title>ricambi</title>
<link type="stylesheet" src="styles/main.css"/>
<link type="stylesheet" src="styles/ricambi.css"/>
</head>
<body>
<table>
.... header stuff ...
</table>
<div class="path">... path ... </div>
... body ...
<table>
.... footer stuff ...
</table>
</body>
</html>
there is no way cinclude can achieve the above. the use of the
'cascading' property of CSS asks for a better mode of styling. I suggest
that wrapping is much better suited for this than fragment inclusion.
--
Stefano.
Re: [FYI] www.ormaz.it usecase
Posted by Stephan Michels <st...@apache.org>.
On 15 Apr 2003, Bruno Dumon wrote:
> Aside from this, with the addition of setup-time profiling to Cocoon's
> profiler, it was remarkable to see that often the setup method of the
> TraxTransformer takes more time than its execution. Still need to dig
> deeper into this...
Yes, the problem is known.
<xslt-processor logger="core.xslt-processor">
<parameter name="use-store" value="false"/>
<parameter name="incremental-processing" value="true"/>
</xslt-processor>
You must set use-store to true, but this will create a memory leak if
you're using the xalan. The memory leak doesn't occur if you're using the
XSLTC. Until now, I havn't got any memory profiling tool to run with
Cocoon.
Perhaps you have more luck, Stephan.
Re: [FYI] www.ormaz.it usecase
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2003-04-15 at 01:19, Stefano Mazzocchi wrote:
> 6) header/footer are not cincluded by they are 'wrapped' by a
> 'style.xslt' stylesheet at the end of every pipeline. This concept of
> XSLT style wrapping is pretty cool and *much* more powerful than any
> server-side-include paradigm.
So if I understand correctly, you're using an XSL that basically
consists of some static HTML with somewhere a <xsl:copy-of select="/"/>.
I'm rather opposed to such constructs, because those XSL's are usually
quite expensive to execute, while doing mostly nothing. If the pages can
be cached, this is not really a problem, but on a dynamic site this can
cause big performance degradations.
The same wrapping behaviour can also be achieved by inversing the way
you do the cinclude: instead of cincluding the header and footer, let
the template page that contains the header and footer cinclude the main
content.
---
Aside from this, with the addition of setup-time profiling to Cocoon's
profiler, it was remarkable to see that often the setup method of the
TraxTransformer takes more time than its execution. Still need to dig
deeper into this...
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [FYI] www.ormaz.it usecase
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/15/03 11:11 AM Sylvain Wallez wrote:
> Would be good if there was a non-official version somewhere
> (cocoondev.org ?) where people could play with it.
I'll do better than this by writing a sample that everyone can use to
see how I did things. Won't work for CNN.com, but might be a good
showcase of some of our more shiny technologies.
--
Stefano.
Re: [FYI] www.ormaz.it usecase
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>Today I went online with my latest creation http://www.ormaz.it which is
>entirely based on cocoon 2.1-dev compiled today. This says it all about
>how confident I am about the code we have in CVS.
>
>I want to tell you how I did it and why I choose it.
>
Thanks for sharing with us !
>The site is very small. The IA diagram [http://www.jjg.net/ia/visvocab/]
>lists no more than 10 different pages or decks of pages. Moreover, I've
>done *all* the work by myself. Everything, from taking the pictures,
>graphic design, CSS/HTML creation, programming, installing.
>
>The result is:
>
> 1) no need for actions, everything is performed with 120 lines of
>flowscript
>
> 2) no business logic in the flowscript: I wrote a few java objects that
>implemented a really-poor-man file repository on top of the file system.
>
> 3) no use of XSP
>
> 4) use of style-clean XHTML for all document markup and velocity as
>template system for simple pages
>
> 5) no database. all information is stored in xml files in a virtual xml
>repository on disk.
>
Could you give us more details about this ? What's a "virtual xml
repository" ?
<snip/>
> 6) header/footer are not cincluded by they are 'wrapped' by a
>'style.xslt' stylesheet at the end of every pipeline. This concept of
>XSLT style wrapping is pretty cool and *much* more powerful than any
>server-side-include paradigm.
>
> 7) the site contains a complete CMS in the administrative section. user
>authentication is done via flowscript, connecting with a very simple
>user registry fed with java.properties file. really-poor-man-acl, you
>could say.
>
> 8) the admin section is heavily DHTML-ized. It works on all 6th
>generation browsers and the user is able to upload images and such
>without requiring rountripping
>
Too bad : the most interesting part isn't accessible :-(
Would be good if there was a non-official version somewhere
(cocoondev.org ?) where people could play with it.
<snip/>
>but even better, go to http://livehttpheaders.mozdev.org and download
>that awesome plugin that shows you the dump of all the headers that flow
>thru between you and the server.
>
Wow, this is cool : you can't know how much I use "wget -S" to get the
headers...
<snip/>
>Hope this helps.
>
Looks nice !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: JSR 170 vs. WebDAV
Posted by Stephan Michels <st...@apache.org>.
> > So, at the end, I don't think there is such a thing as a battle
> > between
> > JSR 170 and WebDAV, but they can easily and happily cohexist, much
> > like
> > CSS and XSTL, but only if used properly.
>
> I agree and I hope Slide could be the RI to show it.
>
> >
> > This 'properly' will have to be defined as soon as the API is made
> > public and a reference implementation is available.
> >
> > David, feel free to add whatever you want/can. TIA.
> >
> > Anyway, hope this helps.
>
> It does.
> Hope that a JSR 170 draft will soon be available.
There is a first draft in the Slide CVS, but it seems to be very
ugly :-/
Stephan.
Re: JSR 170 vs. WebDAV
Posted by Guido Casper <gc...@s-und-n.de>.
Thanks for sharing your thoughts.
Stefano Mazzocchi wrote:
<snip/>
> There is, admittedly, a strong overlap between a JSR 170 repository
> and WebDAV.
>
> Why? well, more or less they are designed to solve the same problem,
> but they do it rather differently. One is a protocol, the other is an
> API.
>
> Both are contracts that isolate a hierarchically-shaped content
> repository from those who want to retrieve/modify/add content into it.
>
> So, the question, IMO, is not properly formulated. A more balanced one
> would be: what is the difference between WebDAV and JSR170-over-RMI?
>
> In that case, the difference is that WebDAV is an HTTP-based protocol,
> while RMI or RMI-over-IIOP are binary protocols and much less
> understood
> by content editors.
>
> So, the other question would be: is JSR 170 capable enough to provide
> an
> API for a direct implementation of WebDAV over that API? yes, I think
> so. i think this is one of the goals. I'll let David talk more about
> this.
>
> This is why Slide makes it a perfect reference implementation: it
> provides both a remotely accessible API using WebDAV instead of
> JSR170-over-RMI but also provides a direct connection to the
> repository
> API in case you don't need a remote repository but want to embed one
> in
> your application.
>
> With my last website, I came out with this simple 'virtual xml
> repository' which is nothing but a file system with a bunch of methods
> calls to move stuff around. That screams for a simple implementation
> of JSR170 but would have been greatly overkill to use webdav as a
> protocol
> for something that was just embeddable (webdav is not easy as a
> protocol, it's a big pain in the ass)
>
> If you look at Subversion, for example, you see more or less the
> webdav equivalent of a web server (in fact, it's based on apache
> httpd 2.0):
> you can't embed it, but they provide a client library that you can use
> to connect to it.
>
> Which approach is better? I honestly can't tell. Reality is that JCP
> standardizes APIs and protocols are much weaker contracts than API
I disagree. Well, actually it depends :-)
But in the case of WebDAV the protocol is the stronger API (while I
appreciate that JSR 170 has a broader scope). Isn't it a coincidence that
HTTP/WebDAV talks about methods :-)
After all I believe JSR 170 targets more towards an end-to-end solution,
while WebDAV allows you to mix and match modules to fit your particular
needs
much more than a Java-API could. WebDAV focusses not only on portability but
on interoperability which allows more for bottom-up approaches.
> because they don't really specify much and the devil is in the
> details.
>
> So, at the end, I don't think there is such a thing as a battle
> between
> JSR 170 and WebDAV, but they can easily and happily cohexist, much
> like
> CSS and XSTL, but only if used properly.
I agree and I hope Slide could be the RI to show it.
>
> This 'properly' will have to be defined as soon as the API is made
> public and a reference implementation is available.
>
> David, feel free to add whatever you want/can. TIA.
>
> Anyway, hope this helps.
It does.
Hope that a JSR 170 draft will soon be available.
Guido
JSR 170 vs. WebDAV
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/16/03 8:36 AM Guido Casper wrote:
> Knowing that you are a member of the expert group
FYI, I resigned from the JSR 170 participation a while ago, but they
somehow forgot to remove me from their mail list. So, even if not
active, I've been watching progress.
> and being myself a big
> time supporter of WebDAV I would be very much interested in your opinion on
> which needs a JSR 170 repository really fits better than a plain WebDAV
> repository (a complete one with DeltaV, ACL and DASL).
This is a damn good question, so I'm copying David which is the spec
lead and CTO of Day Software. We are both bound to an NDA which should
protect the IP discussed there, so we won't be able to get into
technical details until a public draft is made available (damn stupid
JCP, things would progress much faster without this idiotic NDA bindings
that really don't protect anybody, but that's another story).
There is, admittedly, a strong overlap between a JSR 170 repository and
WebDAV.
Why? well, more or less they are designed to solve the same problem, but
they do it rather differently. One is a protocol, the other is an API.
Both are contracts that isolate a hierarchically-shaped content
repository from those who want to retrieve/modify/add content into it.
So, the question, IMO, is not properly formulated. A more balanced one
would be: what is the difference between WebDAV and JSR170-over-RMI?
In that case, the difference is that WebDAV is an HTTP-based protocol,
while RMI or RMI-over-IIOP are binary protocols and much less understood
by content editors.
So, the other question would be: is JSR 170 capable enough to provide an
API for a direct implementation of WebDAV over that API? yes, I think
so. i think this is one of the goals. I'll let David talk more about this.
This is why Slide makes it a perfect reference implementation: it
provides both a remotely accessible API using WebDAV instead of
JSR170-over-RMI but also provides a direct connection to the repository
API in case you don't need a remote repository but want to embed one in
your application.
With my last website, I came out with this simple 'virtual xml
repository' which is nothing but a file system with a bunch of methods
calls to move stuff around. That screams for a simple implementation of
JSR170 but would have been greatly overkill to use webdav as a protocol
for something that was just embeddable (webdav is not easy as a
protocol, it's a big pain in the ass)
If you look at Subversion, for example, you see more or less the webdav
equivalent of a web server (in fact, it's based on apache httpd 2.0):
you can't embed it, but they provide a client library that you can use
to connect to it.
Which approach is better? I honestly can't tell. Reality is that JCP
standardizes APIs and protocols are much weaker contracts than API
because they don't really specify much and the devil is in the details.
So, at the end, I don't think there is such a thing as a battle between
JSR 170 and WebDAV, but they can easily and happily cohexist, much like
CSS and XSTL, but only if used properly.
This 'properly' will have to be defined as soon as the API is made
public and a reference implementation is available.
David, feel free to add whatever you want/can. TIA.
Anyway, hope this helps.
--
Stefano.
Re: [FYI] www.ormaz.it usecase
Posted by Guido Casper <gc...@s-und-n.de>.
Stefano Mazzocchi wrote:
<snip/>
>> wondering about slide and jsr 170 - there are interesting things
>> going on there recently (day.com has contributed a ri for jsr 170).
>>
>> I am evaluating slide for a cms system now. But have not had time to
>> play with slide + cocoon.
>
> JSR 170 is definately the way to go. This is another item in my
> light-year-long todo list :-)
Knowing that you are a member of the expert group and being myself a big
time supporter of WebDAV I would be very much interested in your opinion on
which needs a JSR 170 repository really fits better than a plain WebDAV
repository (a complete one with DeltaV, ACL and DASL).
Guido
Re: [FYI] www.ormaz.it usecase
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/15/03 9:42 AM Jakob Praher wrote:
>> b) flowscript rocks the planet. it will rock even more combined with
>>hot-deployable avalon components.
>>
>
>
> been thinking about this for a long time ...
> It would be interesting, what we need in order to have hot-pluggable
> avalon components - afaik it would not be that hard, the hardest problem
> ist the current EMCs way of getting component information (from the
> monolothic .xconf).
hopefully fortress will help us with this.
> What are the most difficult points here - I guess the component reload
> order and dependencies among different components.
>
> I thought about differntiation between the core (sitemap processor, etc)
> and custom components, that could be more easily reloaded and thus more
> dynamic.
>
>
> For instance for blocks I would keep things simple ( kiss you know ),
> all we need is something like:
>
> interface BlockDeployer{
>
> void insert( Block aBlock ) throws DeployerException;
> void update( Block aBlock ) throws DeployerException;
> void remove( Block aBlock ) throws DeployerExcpetion;
>
> }
>
> I think we could learn much from the Kexts (MacOS Kernel Extensions) or
> Linux Kernel Modules ( insmod, rmmod, ... ).
>
> Sorry for being so evocative again. (but dreaming of cocoon blocks or
> plugins for a long time now ... )
>
> Whats your opinion, state of mind on this?
start small and grow and see where this leads us. As soon as we have a
cocoon 2.1 final I'll start playing with this (time and travelling
permitting, of course)
>> d) flow + inputmodules + redirection from flow totally substitute the
>>need for actions in the sitemap. The elegance of the resulting solution
>>is not even close to be action-based equivalent.
>
>
> sounds interesting. I will try to update my expermiental projects using
> flow.
>
> ....
>
>
>> f) cocoon needs an xml repository as an avalon component accessible
>>from the flow! the use of protocols is simply not enough for the kind of
>>data manipulation required in seriously roundtripping webapps that have
>>to mix, match and change stored xml content. This doesn't need to be an
>>xml database, it could be a virtual file system on top of a blob-capable
>>DB or a CVS view.
>>
>
> wondering about slide and jsr 170 - there are interesting things going
> on there recently (day.com has contributed a ri for jsr 170).
>
> I am evaluating slide for a cms system now. But have not had time to
> play with slide + cocoon.
JSR 170 is definately the way to go. This is another item in my
light-year-long todo list :-)
--
Stefano.
Re: [FYI] www.ormaz.it usecase
Posted by Jakob Praher <jp...@yahoo.de>.
Am Die, 2003-04-15 um 01.19 schrieb Stefano Mazzocchi:
> Today I went online with my latest creation http://www.ormaz.it which is
> entirely based on cocoon 2.1-dev compiled today. This says it all about
> how confident I am about the code we have in CVS.
>
> I want to tell you how I did it and why I choose it.
>
thanks for the info. And thanks for sharing it with us.
> The site is very small. The IA diagram [http://www.jjg.net/ia/visvocab/]
> lists no more than 10 different pages or decks of pages. Moreover, I've
> done *all* the work by myself. Everything, from taking the pictures,
> graphic design, CSS/HTML creation, programming, installing.
Not bad - the site looks really nice.
>
> b) flowscript rocks the planet. it will rock even more combined with
> hot-deployable avalon components.
>
been thinking about this for a long time ...
It would be interesting, what we need in order to have hot-pluggable
avalon components - afaik it would not be that hard, the hardest problem
ist the current EMCs way of getting component information (from the
monolothic .xconf).
What are the most difficult points here - I guess the component reload
order and dependencies among different components.
I thought about differntiation between the core (sitemap processor, etc)
and custom components, that could be more easily reloaded and thus more
dynamic.
For instance for blocks I would keep things simple ( kiss you know ),
all we need is something like:
interface BlockDeployer{
void insert( Block aBlock ) throws DeployerException;
void update( Block aBlock ) throws DeployerException;
void remove( Block aBlock ) throws DeployerExcpetion;
}
I think we could learn much from the Kexts (MacOS Kernel Extensions) or
Linux Kernel Modules ( insmod, rmmod, ... ).
Sorry for being so evocative again. (but dreaming of cocoon blocks or
plugins for a long time now ... )
Whats your opinion, state of mind on this?
> d) flow + inputmodules + redirection from flow totally substitute the
> need for actions in the sitemap. The elegance of the resulting solution
> is not even close to be action-based equivalent.
sounds interesting. I will try to update my expermiental projects using
flow.
...
> f) cocoon needs an xml repository as an avalon component accessible
> from the flow! the use of protocols is simply not enough for the kind of
> data manipulation required in seriously roundtripping webapps that have
> to mix, match and change stored xml content. This doesn't need to be an
> xml database, it could be a virtual file system on top of a blob-capable
> DB or a CVS view.
>
wondering about slide and jsr 170 - there are interesting things going
on there recently (day.com has contributed a ri for jsr 170).
I am evaluating slide for a cms system now. But have not had time to
play with slide + cocoon.
> Hope this helps.
thanks.
-- Jakob
Re: [FYI] www.ormaz.it usecase
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/15/03 10:45 AM Michael Wechner wrote:
>>5) no database. all information is stored in xml files in a virtual xml
>>repository on disk.
>>
>
> what do you mean by "virtual xml repository" and how does it work?
It's something like this:
1) an xml document is really a folder that includes 'document.xml' and
a bunch of binary objects (in this case one or more hi-res images)
2) a folder is given a unique identifier (an incremental number, in
this case)
3) when the user starts editing, the folder is copied into a temporary
directory and the editing continues from there. in case, a file 'locked'
could be placed in the original folder to signify that editing is
prohibited but I didn't implement it because there was no such
concurrency problems.
4) the user can modify the document by uploading different stuff, yet
all the stuff is copied into the temp forder. only when the person
really finishes, the stuff is copied back to the original destination
and it's then visible from the outside (if the document has the 'online'
attribute set in the root element
the code that implements the above is here:
function edit(id,type) {
var home = cocoon.context.getRealPath("/");
var repository = home + type + "/";
var tempId = userid + "-" + java.lang.System.currentTimeMillis();
var temp = repository + "temp/" + tempId;
utilities.copy(repository + id, repository + "temp/" + tempId);
while (true) {
sendPageAndWait("admin/screen/" + type + "/temp-" + tempId, {
username: username, id: tempId });
var action = cocoon.request.getParameter("action");
if (action == "delete") {
utilities.remove(repository + id);
break;
} else {
var output = new java.io.FileOutputStream(temp + "/document.xml");
process("admin/" + type + "/save",{},output);
utilities.save(cocoon.request, temp);
if (action == "finish") {
if (id == "template") id = utilities.getID(repository);
utilities.copy(temp,repository + id);
break;
}
}
}
utilities.remove(temp);
redirect("/admin/" + type);
}
Re: [FYI] www.ormaz.it usecase
Posted by Michael Wechner <mi...@wyona.org>.
Stefano Mazzocchi wrote:
>Today I went online with my latest creation http://www.ormaz.it which is
>entirely based on cocoon 2.1-dev compiled today. This says it all about
>how confident I am about the code we have in CVS.
>
>I want to tell you how I did it and why I choose it.
>
>The site is very small. The IA diagram [http://www.jjg.net/ia/visvocab/]
>lists no more than 10 different pages or decks of pages. Moreover, I've
>done *all* the work by myself. Everything, from taking the pictures,
>graphic design, CSS/HTML creation, programming, installing.
>
>The result is:
>
> 1) no need for actions, everything is performed with 120 lines of
>flowscript
>
> 2) no business logic in the flowscript: I wrote a few java objects that
>implemented a really-poor-man file repository on top of the file system.
>
> 3) no use of XSP
>
> 4) use of style-clean XHTML for all document markup and velocity as
>template system for simple pages
>
> 5) no database. all information is stored in xml files in a virtual xml
>repository on disk.
>
what do you mean by "virtual xml repository" and how does it work?
>
> 6) header/footer are not cincluded by they are 'wrapped' by a
>'style.xslt' stylesheet at the end of every pipeline. This concept of
>XSLT style wrapping is pretty cool and *much* more powerful than any
>server-side-include paradigm.
>
> 7) the site contains a complete CMS in the administrative section. user
>authentication is done via flowscript, connecting with a very simple
>user registry fed with java.properties file. really-poor-man-acl, you
>could say.
>
> 8) the admin section is heavily DHTML-ized. It works on all 6th
>generation browsers and the user is able to upload images and such
>without requiring rountripping
>
>[by setting the 'src' property of an img with the value of the <input
>type="file"> it is possible to visualize the image the user is uploading
>right from disk, without requiring any rountripping. this improves the
>user experience *immensively*!]
>
>[also, using dom cloneNode() it is possible to keep on adding images in
>the form without requiring roundtripping.]
>
it would be nice to have something like that within Lenya. Would you
like to share some of your code?
Maybe this could also be used for other stuff, such as for instance
"links" to related stories, but instead of
reading from the disk, some dialog with the CMS should be started. The
same would be nice for loading
"multimedia-data" (image, audio, video) from a multimedia-repository
located on the server (with some built in search functionality). Hence
data could be easily reused.
>
>My experiences in DHTML programming with 6th browsers has been very
>positive. IE and Moz are pretty much compatible, there are only a few
>issues that really bug me:
>
> 1) if you have <div class="blah"> blah is found in div.class in mozilla
>but div.className in IE! sometimes I think those guys in redmond just
>need more sunshine. I ended up testing for 'document.all' to
>discriminate between the two DOM types.
>
> 2) the event model is *completely* different. there are tricks to make
>the same code work on both, but things like onclick(), onchange() and
>onfocus() never seems to work the same way. I ended up using
>onpropertychange() which is IE-specific. It is amazing how two different
>browsers can claim compliance with a spec, but still be completely not
>interoperable.
>
>To be honest, I have to say this is not only Redmond's fault: the DOM
>spec lacks any connection with the system. So, it says that events are
>pushed, and what is their names, but not *how* and *in what order*!
>
>As a result, I wrote some 300 lines of javascript for the client side
>and only 4 of them were browser-dependent.
>
> 9) I used Mozilla for development. If you are using another browser to
>develop your sites, throw it away and use mozilla. If you haven't done
>so, please read:
>http://devedge.netscape.com/viewsource/2003/mozilla-webdev/
>
>but even better, go to http://livehttpheaders.mozdev.org and download
>that awesome plugin that shows you the dump of all the headers that flow
>thru between you and the server. This saved me hours of cocoon-view
>based debugging, expecially on multipart forms. Not counting the ease of
>use of the javascript console compared to the stinking useless IE error
>popup window. yuck.
>
> 10) at the end, this is a web site designed with *extreme usability* in
>mind. I spent endless hours trying to remove *everything* possible from
>the site without sacrificing the information that the site needed to
>transmit. Also, the site is completely manageable by people who are
>barely able to read email.
>
> 11) despite the ability of IE6 on all machines that need to access the
>internal CMS, I decided *NOT* to use any contentEditable solution but to
>use pure forms for two reasons:
>
> a) their content is always structured
>
> b) web users are used to forms, but not to inline editable pages
>(yet, at least). Forms provide visual semantics which are generally
>understood, inline editing is not standardized and without proper visual
>indications, users assume that if it's not in a textarea, the content is
>simply not editable. I think that even in a future of advanced inline
>editing, forms will still have their pretty consistent usage because of
>the clear visual semantics that are associated to them.
>
yeah, we have made the same experience. But still it is important to
follow both tracks and with XML
it's no problem to do that (at least theoretically).
>
>
> - o -
>
>Lessons learned:
>
> a) cocoon can be very useful for small sites, but the hard part is
>*not* to use all its features and get down to easy stuff like a velocity
>template that generates XHTML. Still, it can provide very useful
>features even in that case (think style wrapping instead of
>header/footer inclusion)
>
> b) flowscript rocks the planet. it will rock even more combined with
>hot-deployable avalon components.
>
> c) LiveConnect (the glue between javascript and java) makes it hard to
>abuse the flow to write business logic in it. Even after a few lines of
>having to call the classes by their full package names, you spin it off
>into their own classes and call them. This turns out to be very
>straightforward and keeps the flow *very* clean.
>
> d) flow + inputmodules + redirection from flow totally substitute the
>need for actions in the sitemap. The elegance of the resulting solution
>is not even close to be action-based equivalent.
>
> e) sessions and continuations do need to cohexist and they do very well
>already.
>
> f) cocoon needs an xml repository as an avalon component accessible
>from the flow! the use of protocols is simply not enough for the kind of
>data manipulation required in seriously roundtripping webapps that have
>to mix, match and change stored xml content. This doesn't need to be an
>xml database, it could be a virtual file system on top of a blob-capable
>DB or a CVS view.
>
>Hope this helps.
>
sure it does.
Thanks
Michael
>
>
>
Re: [FYI] www.ormaz.it usecase
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/15/03 9:06 AM Leszek Gawron wrote:
> On wto, kwi 15, 2003 at 01:19:59 +0200, Stefano Mazzocchi wrote:
>
>>http://devedge.netscape.com/viewsource/2003/mozilla-webdev/
>
> This is a stupid question but I cannot find the answer on the web: is there a
> possibility to display xml files IE5 like?
Mozilla 1.3+ supports IE-like xml tree visualization in case there is no
<?xml-stylesheet?> PI included in it. Otherwise, it process it with the
stylesheet (either CSS or XSLT)
--
Stefano.
Re: [FYI] www.ormaz.it usecase
Posted by Leszek Gawron <ou...@vip.net.pl>.
On wto, kwi 15, 2003 at 01:19:59 +0200, Stefano Mazzocchi wrote:
> http://devedge.netscape.com/viewsource/2003/mozilla-webdev/
This is a stupid question but I cannot find the answer on the web: is there a
possibility to display xml files IE5 like? I know I can use DOM Inspector but
it does not display the attributes inline which bugs me a lot.
LG
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ ouzo@vip.net.pl _\\()//_
.'/()\'. Phone: +48(600)341118 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
Re: [FYI] www.ormaz.it usecase
Posted by Stefano Mazzocchi <st...@apache.org>.
on 4/15/03 11:47 AM Jeremy Quinn wrote:
> Drag, I cannot get the plugin to load .... MacOSX?
Yep, mozilla 1.3 on mac is buggy on .xpi loading. Get a nightly build
for 1.4a, I can testify it's pretty damn solid. I'm using it right now
as I type :-)
>
>> 10) at the end, this is a web site designed with *extreme usability*
>>in
>>mind. I spent endless hours trying to remove *everything* possible from
>>the site without sacrificing the information that the site needed to
>>transmit. Also, the site is completely manageable by people who are
>>barely able to read email.
>
>
> sounds like my client ;)
Sounds like 99.9% of the world population so get used to it :-)
--
Stefano.
Re: [FYI] www.ormaz.it usecase
Posted by Upayavira <uv...@upaya.co.uk>.
> 7) the site contains a complete CMS in the administrative section.
> user
> authentication is done via flowscript, connecting with a very simple
> user registry fed with java.properties file. really-poor-man-acl, you
> could say.
Are you able to offer a code sample for this authentication method?
Also, how did you write your content back to the file store? Not used flow yet, but am
quite willing to.
I have a really big need for a 'poor-man's-cms' for which this technique could be really
useful.
> Hope this helps.
It does!
Upayavira
Re: [FYI] www.ormaz.it usecase
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Tuesday, April 15, 2003, at 12:19 AM, Stefano Mazzocchi wrote:
> Today I went online with my latest creation http://www.ormaz.it which
> is
> entirely based on cocoon 2.1-dev compiled today. This says it all about
> how confident I am about the code we have in CVS.
>
> I want to tell you how I did it and why I choose it.
Thanks for this Stefano, I do promise to do something similar for the
iNIVA site, but while I am still busy working on it, I don't have time
;)
> The site is very small. The IA diagram
> [http://www.jjg.net/ia/visvocab/]
> lists no more than 10 different pages or decks of pages. Moreover, I've
> done *all* the work by myself. Everything, from taking the pictures,
> graphic design, CSS/HTML creation, programming, installing.
>
> The result is:
>
> 1) no need for actions, everything is performed with 120 lines of
> flowscript
good, it would be really interesting to see ....
> 2) no business logic in the flowscript: I wrote a few java objects
> that
> implemented a really-poor-man file repository on top of the file
> system.
this would be interesting to see as well ;)
> 3) no use of XSP
good!
> 4) use of style-clean XHTML for all document markup and velocity as
> template system for simple pages
you like velocity, don't you ;)
tbh I have not used it .... my immediate reaction to seeing a page of
velocity was yuk, that's ugly ;)
> 5) no database. all information is stored in xml files in a virtual
> xml
> repository on disk.
nice, it would be great to hear more about this
> 6) header/footer are not cincluded by they are 'wrapped' by a
> 'style.xslt' stylesheet at the end of every pipeline. This concept of
> XSLT style wrapping is pretty cool and *much* more powerful than any
> server-side-include paradigm.
Hmmm, not entirely convinced yet ...
> 7) the site contains a complete CMS in the administrative section.
> user
> authentication is done via flowscript, connecting with a very simple
> user registry fed with java.properties file. really-poor-man-acl, you
> could say.
now this is where I get really interested ;)
> 8) the admin section is heavily DHTML-ized. It works on all 6th
> generation browsers and the user is able to upload images and such
> without requiring rountripping
>
> [by setting the 'src' property of an img with the value of the <input
> type="file"> it is possible to visualize the image the user is
> uploading
> right from disk, without requiring any rountripping. this improves the
> user experience *immensively*!]
very cool, I do this in XMLMind too ....
> [also, using dom cloneNode() it is possible to keep on adding images in
> the form without requiring roundtripping.]
<snip/>
> As a result, I wrote some 300 lines of javascript for the client side
> and only 4 of them were browser-dependent.
I always refused to work with dHTML, for these very reasons, hmmm, I am
beginning to loose out!
>
> 9) I used Mozilla for development. If you are using another browser to
> develop your sites, throw it away and use mozilla. If you haven't done
> so, please read:
> http://devedge.netscape.com/viewsource/2003/mozilla-webdev/
yes, I used this lot, Mozza is top!
>
> but even better, go to http://livehttpheaders.mozdev.org and download
> that awesome plugin that shows you the dump of all the headers that
> flow
> thru between you and the server. This saved me hours of cocoon-view
> based debugging, expecially on multipart forms. Not counting the ease
> of
> use of the javascript console compared to the stinking useless IE error
> popup window. yuck.
Drag, I cannot get the plugin to load .... MacOSX?
> 10) at the end, this is a web site designed with *extreme usability*
> in
> mind. I spent endless hours trying to remove *everything* possible from
> the site without sacrificing the information that the site needed to
> transmit. Also, the site is completely manageable by people who are
> barely able to read email.
sounds like my client ;)
> 11) despite the ability of IE6 on all machines that need to access the
> internal CMS, I decided *NOT* to use any contentEditable solution but
> to
> use pure forms for two reasons:
>
> a) their content is always structured
>
> b) web users are used to forms, but not to inline editable pages
> (yet, at least). Forms provide visual semantics which are generally
> understood, inline editing is not standardized and without proper
> visual
> indications, users assume that if it's not in a textarea, the content
> is
> simply not editable. I think that even in a future of advanced inline
> editing, forms will still have their pretty consistent usage because of
> the clear visual semantics that are associated to them.
hopefully this will change ....
> Lessons learned:
>
> a) cocoon can be very useful for small sites,
agreed!
> but the hard part is
> *not* to use all its features and get down to easy stuff like a
> velocity
> template that generates XHTML. Still, it can provide very useful
> features even in that case (think style wrapping instead of
> header/footer inclusion)
>
> b) flowscript rocks the planet. it will rock even more combined with
> hot-deployable avalon components.
yummy!
> c) LiveConnect (the glue between javascript and java) makes it hard to
> abuse the flow to write business logic in it. Even after a few lines of
> having to call the classes by their full package names, you spin it off
> into their own classes and call them. This turns out to be very
> straightforward and keeps the flow *very* clean.
yeah, this is good
> d) flow + inputmodules + redirection from flow totally substitute the
> need for actions in the sitemap. The elegance of the resulting solution
> is not even close to be action-based equivalent.
I forget about input modules WRT flow ....
What are you doing with them there?
> e) sessions and continuations do need to cohexist and they do very
> well
> already.
>
> f) cocoon needs an xml repository as an avalon component accessible
> from the flow! the use of protocols is simply not enough for the kind
> of
> data manipulation required in seriously roundtripping webapps that have
> to mix, match and change stored xml content. This doesn't need to be an
> xml database, it could be a virtual file system on top of a
> blob-capable
> DB or a CVS view.
Hmmm, interesting ...
> Hope this helps.
many thanks
regards Jeremy