Hi Erin,
On Sep 27, 2007, at 10:15 PM, Erin Schnabel wrote:
> On 9/26/07, Vincent Massol <[EMAIL PROTECTED]> wrote:
>> Hi xwiki devs,
>>
>> This is a summary of the decisions so far and the remaining
>> questions. This
>> is also the outcome of my discussion of today with Mikhail on skype.
>>
>> 1) We'll be able to import all syntaxes.
>>
>> 2) An XWiki instance will use a single syntax at a time. Once the
>> database
>> is created using that syntax it won't be possible to change it
>> (except by
>> doing an export and reimport).
>
> This is the only thing that makes sense to me.
>
>> We also need to decide what syntax we use by default OOB. I
>> propose we use
>> the current xwiki syntax for some time and then switch to the
>> Wikimodel one
>> (Common Syntax) later on.
>>
>> 3) All pages will be able to be exported to any syntax. Some
>> elements have
>> no equivalent in other syntaxes and when this happens a warning
>> will be
>> displayed and the elements in question ignored.
>
> OUCH. It's the only possible answer, but OUCH. I can just see the
> complaints about data-loss piling up.. This will have to be
> well-documented, perhaps including some tips about a) how to back
> things up for real, and b) how to identify those areas later to assess
> the damage...
>
> Would you convert the syntax in the document history, too? Or does a
> switch in syntax imply that the history is wiped... the document
> history is very sensitive to random mucking around, I've found.
These exports would be only useful for people moving away from xwiki
I think and they would be useful only to import into another wiki.
The way to import history in each wiki is different I guess so saving
the history in a format specific to each wiki will be too much work
for us so I'd say not to exporting the history. However exporting any
version of a page is doable easily.
>> 4) Mikhail has agreed to modify wikiModel to add macro block
>> recognition.The
>> syntax isn't fully defined yet but it'll be something like:
>>
>> {xxx param1=value1 param2=value2}
>> ...
>> {/xxx}
>>
>> (param1='value value' and param1="value value" will also be
>> supported)
>>
>> This means we'll be able to have a common syntax for xwiki's
>> macros and also
>> for groovy code:
>>
>> {groovy}
>> ...
>> {/groovy}
>>
>> And also for HTML blocks:
>>
>> {html}
>> ...
>> {/html}
>
> Consistency is good, as is the lack of smashed-together-curly-braces.
>
> If we demarcate all scripts in nice little blocks like this, will the
> WYSIWYG editor be smart enough to leave it alone?
Yep that's the point too but it means anything inside will be left
alone, including wiki syntax and HTML. But that's fine I think.
>> 5) We need to decide if we want:
>>
>> A) No velocity block but document properties/metadata to tell
>> xwiki to
>> render the page using velocity. A user putting velocity code in a
>> page will
>> have to check a box somewhere to say that this is a velocity page.
>>
> ...
>> OR
>>
>> B) Velocity blocks same as what exists for groovy/macros/html,
>> namely:
>>
>> {velocity}
>> ... velocity code with wiki syntax allowed
>> {/velocity}
>>
>> Note1: For B) we would allow putting wiki syntax inside the
>> velocity block.
>> Technically we'll apply the velocity rendering and then re-apply
>> wikimodel
>> on the result.
> ...
>> My preferences goes to B) and I'm proposing to use that.
>
>
> The compatibility flag in xwiki.cfg would help, but the problem is
> that I wouldn't ever be able to turn the flag off if I have a large
> legacy database... which means none of my new documents get whatever
> performance benefit might be gained.
You'll get some benefits (since Wikimodel is faster than Radeox) but
not all performance gains.
> I would like to say: "I'm running in a compatibility mode, and have
> flagged all of the documents that pre-dated the new syntax processing
> model. Shame on me if we don't start using the scripting blocks for
> new documents."
Yes I guess that's possible but requires more work. We have so much
work to do already that I think this would be left for later or left
for the community to implement with patches.
> As far as adding {velocity} {/velocity} around content when in
> compatibility mode.. that would apply to all pages, which means all
> content would get passed through the velocity renderer, right?
Right
> I would think that whether or not wikitext (or raw html for that
> matter) is allowed within a script block {script} {/script} would
> depend on the nature of the language being invoked, right?
Right. It would be allowe for Velocity but not for Groovy for example.
> Velocity is easily integrated with wikitext and html without a lot
> of fuss, so, in my view, you would be obligated to allow html and
> wikitext within that block (generally agreed).
Yep, that's what I proposed.
> An html block would specify that you wouldn't want any wiki parsing
> at all, right?
Yes
> (wait a minute, isn't that what the pre tags were
> supposed to do?).
Yes. We'll deprecate the pre tag then since an html tag makes more
sense and is better named IMO.
>> 6) Mikhail is going to add support for recognizing XML tags in the
>> wikimodel
>> parser so that onOpenXmlTag()/onCloseXmlTag() events are called in
>> listeners). This is needed for point 7 below.
>>
>> 7) We need to allow intermixing velocity/HTML and wiki syntax
>> easily. For
>> this our listener (the code that listens to {velocity} events)
>> will evaluate
>> the content using velocity and will call wiki model again on the
>> resulting
>> code. Since wikimodel requires HTML to be in a block ({html} for
>> us) we'll
>> use a different wikimodel listener that intercepts the
>> onOpenXmlTag/onCloseXmlTag so that it'll output XML tags with no
>> modifications (the standard HTML listener generates < and >
>> for < and
>>> ). This will allow writing:
>>
>> {velocity}
>> <div>
>> <h1>Hello $customer.Name!</h1>
>> <table>
>> #foreach( $mud in $mudsOnSpecial )
>> #if ( $customer.hasPurchased($mud) )
>> <tr>
>> <td>
>> * [link>$flogger.getPromo( $mud )]
>> </td>
>> </tr>
>> #end
>> #end
>> </table>
>> </div>
>> {/velocity}
>
> It seems there is this assumption that people either write wiki OR
> they write html. I write both.
Ah I see... You mean when not using the {velocity} tag I guess. Good
point....
hmm....
I guess we could allow the {html} macro to interpret wiki syntax too.
We could have a parameter like this:
{html renderWikiSyntax=true}
...
{html}
WDYT?
> At the same time. I am a nightmare for
> anyone even thinking about stuff in neat little either/or packages. I
> write a bunch of wikitext, and then throw some div tags around bits of
> it, or to make a specific kind of heading that the silly syntax won't
> generate for me, or..
>
> I don't know that much about wikimodel, but I have to assume it isn't
> going to complain if you intermix html in your wikitext. The only
> benefit I see of the {html}{/html} tag is if the WYSIWYG editor will
> then be smart enough not to bother messing with it. at all.
Yes, it's possible to also have XHTML (not HTML) with the new
onOpenXmlTag/onCloseXmlTag() that Mikhail is going to add. So we
could have a listener that outputs the XHTML as is.
It's a good question, I'm not sure sure which is best. Right now I'd
be tempted to use the {html} notation proposed above (with the
renderWikisyntax parameter).
> Does the templating model change? All of the templates/skins to date
> use velocity, and are rendered using velocity, which seems not to be
> an issue. Am I right in assuming (therefore) that this discussion
> applies only to "documents" in the DB, and not to templates or skins?
> What happens when portions of the templates are defined in a skin
> document in the DB?
Templates will be treated the same as documents (as is the case now I
think).
The templates would use the same {velocity} macro.
> It seems semi-tangential to ask questions about skin/template
> rendering, but I feel there is a significant amount of interdependency
> between the skin and the content, especially if you consider the
> #panel macros, for example. The #panel macros are a) velocity macros,
> b) defined in files in the filesystem, and c) are included and used by
> every document defining a panel.
>
> Do changes to the rendering/parsing API require skin/template *.vm
> files to be updated with {velocity} {/velocity} tags? Or would the
> velocity engine continue to pre-read and cache those files as it does
> now...
hmm... Are they cached now? I don't see how they could be since it
would mean the velocity doesn't get executed at each request.
Yes, I would assume we would use {velocity} blocks.
> A bunch of other random questions:
>
> Is there something we have to keep in mind here RE: document content
> vs. object field content (which already has a flavor of content
> rendering attribute)?
We need to bring more consistency to this area too but it's another
topic I think.
> Would you have to make script {script} {/script} blocks in textarea
> content of objects? (I'm thinking Panels, so I'd say yes).
I think yes.
> Will the
> page parser panic if you either include the content of a field
> containing a block within a different content block? e.g.
> {velocity}
> .. find an object of type x (with field y)
> display object field y:
> {groovy}
> crazy scripting, man
> {/groovy}
> {/velocity}
That will work. The velocity macro will run velocity on the whole
block and then pass the result back to wikimodel. Wikimodel will see
the {groovy} macro and the groovy macro will be executed.
> As far as use cases go, mine is just this:
>
> A LOT of pages (some of which have an extensive history and a lot of
> attachments): largest portion have mix of html and wiki; second
> largest is mix of velocity, html, and wiki; last is pages with groovy
> (usually on pages also containing html, wiki, AND velocity).
>
> That was rather stream-of-consciousness. So tell me if I was
> confusing.
Good questions ;)
Thanks
-Vincent
_______________________________________________
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
