cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Wyona / Xopus (IE vs.Mozilla)
Date Fri, 15 Mar 2002 12:30:06 GMT
Robert Koberg wrote:

> >Which one, I'm curious.
> >
> I thought it was obvious I was talking about mine :) The one that is due
> to be released in January of 2002 :)

Ah, well, I explicitly said *existing*. :)

> I believe it has improved a great deal since you saw it last. But this
> does not meet your needs because it is not cross platform and does not
> currently set up a dynamic site, just static.  I have a previous
> Dreamweaver SE working on the JavaScript to get it as professional as it
> can get. It does not actually run in cocoon. To get it to work in cocoon
> would require major rewrites of my XSLT (my tool is mostly XSLT and XML,
> heavily using the xsl document function).
> I want to make my "storyboard" tool *export* a cocoon site. The
> storyboard is 'active' or 'live' meaning that it should change as your
> site structure and content changes. I see cocoon being a later stage in
> the final product, not for text editing (at least for my needs). I see a
> good spot alongside things like cocoon. I believe that in the beginning
> stages of a site's development you have to be much more fluid than you
> are allowed with cocoon (that is my impression since I can't quite grasp
> everything about cocoon).
> I have only taken static sites on as jobs recently. But of course a
> static site can be changed daily given the ability to generate at will.
> I just took a project where i am converting a workbook to an online
> version. This will eventually live in cocoon.


> ><snip/>
> >
> >
> >Yes, more or less, but semi-structure at the editing level is definately
> >what we need: less freedom than Word but more freedom than forms, all
> >without moving from your browser.
> >
> >
> >>>And this is *NOT* currently possible in any browser in the world!
> >>>
> >>I must be missing something.
> >>
> >
> >My experience indicates that it's not possible to use contenteditable
> >without sacrificing some layout changes due to the rectangular-ness of
> >the implementation.
> >
> >I'm not saying it's not possible *at all* (it is, in fact) but that
> >isn't good enough for my quality standards (and my girlfriend's, she's
> >even more picky than I am... even a pixel off when I turn
> >contenteditable on and she screams!)
> >
> I am with her (and you, but she is probably more attractive :). I don't tolerate pixel
shifts (from my CDROM days...).  I don't have the experience of contentedtiable changing my
layout, though. When we added our visual rollover indicator (dashed border on rollover of
an editbale region) it shifts by the size of the border. We *fixed* that by swapping a background
color border with the dashed one. That is the only thing. The tool is, however, in complete
control of the HTML written on the page during editing. We are not trying to make this work
with just any HTML.

unlike I'm trying to do :)

> >>>This was only an example. And, BTW, I think you could do *very* powerful
> >>>semi-structured editing with just <div> and <span>
> >>>
> >>Yes, I agree. There are many different types of documents to edit! For
> >>example an article should be much more free-form than a use-case :) The
> >>transformation determines which javascript parser script to include;
> >>parser_article.js or parser_use-case.js
> >>
> >
> >Exactly! This is why I would like this editing-driving javascript to be
> >created on the server directly by transforming the XMLSchema describing
> >the document structure (we could add cocoon-specific namespaced
> >information about the client-side user behavior that would be turned
> >into javascript logic for the client side)
> >
> This sounds really cool. I really have to start learning about schemas
> :) I have been able to get away with DTDs... On this, I am kind of torn
> between the time it would take to create the XSLT versus the time it
> would take to just write the JS.
> We have been writing each js parser by hand. This is most frustraing
> when trying to deal with content that was pasted in from MS Word (which
> I am thinking should not be allowed at this point).
> <snip/>
> >
> >lowercase HTML is more compressible. This is the reason why they forced
> >you to use lowercase and I *do* agree it's a good thing. Using case to
> >differentiate syntax is a hack: people should not edit markup by hand
> >anyway and if they do, they sure know how to indent it properly so no
> >need for HTML and then having 20% of the world's bandwith wasted because
> >of that.
> >
> This is the first good explanation I have heard (and now it makes
> sense). I asked the w3c-html group and they came up with very lame
> answers (mostly that it was just arbitrary).
> But this hack is a useful one (though now I see it's problems). At
> LearningNetwork (read more about it on f* :) we had
> more-skilled people set up the XSLT and then this was turned over to
> HTMLers to tweak to a designer's specification. The difference between
> the uppercase text and lowercase text was invaluable. If they want to
> save bandwidth they should criminalize images for Navs :). I don't
> understand why you say people should not edit markup by hand, other than
> the obvious that they will f*ck it up. But I don't want to spend money
> on a valueable person going through rounds (and rounds and rounds,
> etc...) of tweaking XSLT's HTML. This is perfectly able to be done by a
> less skilled (and less expensive) person. Also, it would be tough to
> keep a skilled person if they spent a good part of each day tweaking the
> HTML part. arrrgggghhhh....

What you wnat can be done with a namespace-based syntax highlightning
XML editor, not need for uppercase/lowercase hacks, IMO.

Unfortunately, there aren't any available :)

> >
> >>In my site.xml config document (and a corresponding content.xml that
> >>further describes each individual content piece) I describe the site
> >>hierachically with folders and pages (mirroring what the site structure
> >>would be if not dynamic). At the folder and page level I set the columns
> >>for the page. Inside of the columns I put XML content pieces which
> >>determine the rows or individual CONTENTEDITABLE regions in each column.
> >>The content pieces at the folder level cascade down to the page level
> >>(unless overridden). By having the hierarchical representation you can
> >>build nav's and links on the fly (either dynamic or static depending on
> >>whether you are in dev or generating). Each content piece has an owner.
> >>When a user hits a page they can only edit those pieces that they own
> >>(rollover editable area and user sees a light outline, click on an
> >>editable area and the background color changes in that section). Once
> >>they click on the editable area, setup what you need to and let them
> >>have at it.
> >>
> >>I give the user the oppourtunity to generate the site (SAX
> >>ContentHandler going through the site.xml triggers transformations on
> >>cahced XSLT).  So for a simple site you can use the same virtual host to
> >>see the Dev (and QA) version which is dynamic and using the config to
> >>guide the transformations pulling content from WEB-INF or a DB (I like
> >>text files). When ready to go to QA they generate the site to static
> >>HTML which populates the docroot writing out pages according to the
> >>config. When QA'd they can just copy the generated site to the live server.
> >>
> >
> >Hmm, that would make a great cocoon sample, can you share it with us? :)
> >
> As I mentioned earlier, I intend to set up my storyboarding tool to
> export a cocoon site, but the tool itself is not in cocoon.

Ok, but would you make it open source?

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message