cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Koberg <...@koberg.com>
Subject Re: Wyona / Xopus (IE vs.Mozilla)
Date Wed, 13 Mar 2002 13:50:06 GMT


Stefano Mazzocchi wrote:

>"Robert S. Koberg" wrote:
><snip>
>
>
>Don't tell me, my girlfiend is one of them :) and given the overall
>beauty of macosx I might turn into one of them myself shortly :)
>

I am about 70% on OSX now that I have a mozilla mail client :) Have you 
burned a DVD yet? (: rhetorical :)

>
> 
>
>>>If you try Mozilla Composer, it is fully capable of performaing
>>>non-rectangular editing of text... for example, text flows around
>>>images, so my wild guess would be that by merging the editing
>>>capabilities of the editor XPCOM component and the rendering capability
>>>of the Necko XPCOM component, we can have the behavior we want.
>>>
>>I have never tested on Mozilla before (never had the req). I am using it
>>now. Very cool, but the memory... There are a couple of other IE
>>features that would be good to have (don't know if they already have it...):
>>
>>- control over the right-click (context sensitive menu)
>>
>
>You get this with XUL out-of-the-box.
>
>>- modal and modeless dialogs
>>
>
>could be that XUL has this but I'm not sure.
> 
>
>>>Even the best inline editor existing (q42's LIME, see
>>>www.q42.nl/products/lime) is based on contentEditable and thus inherits
>>>this 'rectangular only' behavior that messes up layout.
>>>
>>I believe there is a better one out there :)
>>
>
>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 :)

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.


>>>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....

>
>>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.

best,
-Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message