17 Mar
2010
17 Mar
'10
2:24 p.m.
On 03/17/2010 03:15 PM, Jerome Velociter wrote:
[snip]
Yes, that's what I had in mind.
The fact that some extensions need to change the html of the annotations
interface. For example, the way an annotation is displayed when hovered in the
text, or the edit form (point 3/ above).
Anca
Ideally
yes, i've been thinking about this in the past days, and I still
think
it's too much.
1/ because it would mean maintaining an annotations js API, which sounds
a bit
too much: we need to commit to it, make it backwards compatible, etc.
However if
it's part of the platform, then it follows all platform rules, among
which js
API. "plugin system of some sort" it's a bit too much...
2/ because chances are it won't be enough unless very granulated, and
the finer
the granulation, the bigger pain 1/ is
3/ because customizations are not only at .js level, they would be at
the macros
& scripts generating the UI level too (documents now but templates in
the
integration), for which building APIs is a bit harder (there is no way
to
override a macro in velo iirc) and, again, "plugin system of some sort"
sounds a
bit too much and chances are it won't be enough.
Actually .js can be handled, to some extent, using events. And we can consider that we ignore 'the html
issue' since it can all be
modified
from js provided that appropriate handlers can be registered.
What is the 'HTML issue' ? I don't understand what you mean by that.
Jerome.
I don't like the second part that much though.
Thanks,
Anca
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
>
> However, for the moment (2.3M1), that's quite a bit of refactoring
> (the
> integration) which i'm not willing to do.
>
> So for M1 it would be either:
>
> 1/ all in xar (js, css, script documents with annotation forms)
If it's only for M1 as a path to have the feature integrated in
templates
and resources, it means you are creating yourself a challenge for the
migration path (you will need to find a way to delete or ignore the
always-loaded SX from the wiki if at some point the make their ways
into
the core).
That's a good point. Is it an option to have good release notes from M1
to M2
and RCs and having it done nice for final?
can the migration be handled with good release notes between milestones
and RCs?
(as in I agree this would be a mess for a final, but milestones have a
different
status...)
Thanks,
Anca
> 2/ js& css in resources, script documents with annotation forms&
> other
> scripted UI in .xar
What does form and scripted UI means ? They are scripts that generated
HTML loaded by AJAX in the pages ? (for example in the docExtra tabs ?)
Or
is it something else ?
yes, that's what it means: the docExtra tab, all the annotation forms
(create,
edit, display, etc) are html fetched with ajax from generating scripts
in xwiki
docs ftm, none is created from javascript, for customizability purposes.
>
> My vote goes for 1/ since it's less mess.
0
Jerome.
>
> WDYT?
>
>>
>> Thanks
>> -Vincent
>>
>>>
>>> Jerome.
>>>
>>>
>>>
>>>>
>>>> Anca
>>>>
>>>>>
>>>>> Jerome.
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Anca
>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> -Vincent
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs