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.
Ok
> ><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*ckedcompany.com :) 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.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
