Re: [xwiki-devs] [Rendering] Image support & Parameters for links/images

ok so far we have: * Jerome: iii) * Anca: iii) * ThomasE (non-binding): iii) * Vincent: iii) Sergiu, ThomasM, JV, Marius, Asiri (and other committers): are you ok with iii). Barring any more answers, I'll start implementing it in 1 hour (it seems the right solution to me anyway).

Implementation note: I'll still introduce an onImage() event and an ImageBlock class. Also as Jerome mentioned I'll use the text specified as the label as is. Thanks -Vincent On Oct 28, 2008, at 6:53 AM, Jerome Velociter wrote: > I'd go for iii), without parsing the label (use "hello **world**" if > it > is, not make it "hello world") > > Jerome. > > Vincent Massol wrote: >> On Oct 27, 2008, at 2:01 PM, Vincent Massol wrote: >> >> [snip] >> >>> Basically there are now 2 >>> possibilities: >>> >>> i) using a special syntax for parameters for links and images. For >>> links that could be [[label>>reference>>>parameters]]. Note that >>> we >>> might also need such a special syntax for inline verbatim blocks. >>> ii) using 2 generic syntaxes for parameters: >>> >>> (% ... %) for applying parameters only to the next element >>> {% ... %} ... {%%} for applying parameters to the elements inside >>> >>> Which one do you prefer? >>> >>> I think we have an issue for i) anyway (for verbatim inline >>> elements >>> for example). >>> >>> My preference goes to ii) [EDITED: was i)]. >> After speaking to Mikhail (wikimodel creator) there's a third >> possibility: >> >> iii) using the same syntax for links, images and attachments. >> Namely: >> >> Links: >> [[label>>reference||params]] >> >> Images: >> [[label>>image:wiki:Space.Page^my.png||params]] >> >> Attachments (download link): >> [[label>>attach:wiki:Space.Page^my.png||params]] >> >> This means that it would also be possible to use links, images and >> attachments directly in the text using the form: >> >> This is a http://... URL >> This is an image:my.png image >> This is my word attach:my.doc document >> >> Notes: >> * The "label" for images would correspond to the alt/title >> attribute. >> Thus the wiki syntax inside would be transformed into text (for >> example: "Hello **world**" would generate "Hello world") >> * It would currently not be possible to disambiguate between a >> subwiki >> named "image", "attach" and displaying an image or linking to an >> attachment. This would be fixed later on when we change the FQN >> (Fully >> Qualified Name) for Documents in order to support nested spaces. >> * This means that we can keep using (% %) notation and there's no >> need >> to define a new {% ... %} notation. >> * It means we need to introduce the "||" separator for link >> parameters >> * It is completely inline with the wikimodel way of handling >> images. >> * There's no need to introduce a new onImage() event. However we >> might >> want to rename our begin/endLink() events to beginReference()/ >> endReference(). >> >> I personally like this solution except for the fact that since >> we've >> introduced wiki syntax in place of labels we would be tweaking the >> model a bit since there's no need for begin/end for images. That >> said >> we could also add an onImage() event and emit it at the parser >> level >> so that the label would always contain pure text (if we have >> "hello >> **world**" we would use "hello **world**"). >> >> I'm hesitating between ii) and iii). >> >> WDYT? >> >> Thanks >> -Vincent >> >>>> so >>>> +1 for 1)a) only if we can do it for all inline elements. >>>> >>>> Which brings us to images: >>>> I find a wiki syntax quite suitable, for consistency reasons >>>> (with >>>> links, for >>>> example). ! is a pretty used character, even duplicated, so I'd >>>> go >>>> for another >>>> one: pipe (hard to find on some kbds, though), @ (semantically >>>> associated with >>>> emails, though), # (already taken), & ? >>>> >>>> so >>>> +1 for wiki syntax for 2) >>>> >>>> Happy coding, >>>> Anca