Jerome Velociter wrote:
> Hello Pascal, All,
>
> See below
>
> Pascal Voitot wrote:
>> On Fri, Oct 31, 2008 at 6:09 PM, Jerome Velociter <[EMAIL PROTECTED]> wrote:
>>
>>> Pascal Voitot wrote:
>>>> Hello,
>>>> I used JSX to write a GoogleMap extension...
>>>>
>>>> My problem was the loading of the google entry library needed to get a
>>>> reference to "google" object in javascript.
>>>> How do you manage this without modifying the skin template?
>>>>
>>>> Actually, this was not possible with JSX because JSX is not able to
>>> manage
>>>> external JS files as we have already explained in another mail.
>>>> So I modified the Skin template which is not satisfying to me.
>>>> Then, I also modified JSX to manage this in order to evaluate the idea
>>> and I
>>>> find it much practical because I can lazily load any Javascript extension
>>>> now and I don't fear security issues in my case because my site should be
>>>> opened on internet... ;)
>>>>
>>>> Anyway, my googlemap extension was only javascript functions in JSX... I
>>>> could have written a Velocity Macro but needed only some JS functions
>>> that I
>>>> call in the middle of my XHTML/JS...
>>>>
>>>> Don't understand why you should write a real macro instead of a velocity?
>>>> there is nothing to do on the server side for this, isn't it? Only some
>>>> formatting of HTML/JS...
>>> For the two reasons I mentioned in the first mail :
>>>
>>> 1. Something like
>>>
>>> {{map location="10, rue Pernety, Paris, France" message="One of the
>>> XWiki offices"/}}
>>>
>>> is nicer and more explicit for the users of wiki editor than the
>>> following in velocity :
>>>
>>> {{velocity}}#map("10, rue Pernety, Paris, France" "One of the XWiki
>>> offices" "" "" "" ""){{/velocity}}
>>>
>> yes this is not very nice :)
>>
>>
>>> 2. In velocity, we have to give a value (even empty one) for all
>>> parameters (I added above a lot of empty values just to show that if the
>>> macro supports many optional parameters, this is how the velocity call
>>> will look like).
>>
>>> And I would add...
>>>
>>> 3. We can write unit tests/rendering tests for an actual XWiki Syntax
>>> 2.0 macro. This is another advantage, it will make it easier to add
>>> parameters or new implementations (viamichelin for example ;)) to the
>>> macro.
>>>
>> but you have also to write and compile code where there is no real server
>> code actually :)
>
> I tend to agree with your point, this is why I initially emitted the
> reserve in point 3. above.
s/above/below (in the initial mail)
> Now that I explored more that path and started to implement the macro, I
> think it worth it at the end.
> I am at a point where the macro is not aware of the underlaying
> implementation (google map, yahoo map, etc.) and where one can add an
> implementation just by registering and configuring a component in
> plexus.xml and write the javascript extension for that implementation in
> a wiki page (thus, not writing a single line of java code, and not
> having to recompile).
> What the macro does is to generate the JSX "use" calls (I currently
> generate a velocity macro for that, maybe I could directly call the jsx
> plugin, this is to be investigated further), and initialize a Javascript
> object (by generating a (x)html macro with a script tag). The
> abstraction of the implementation is currently realized using
> duck-typing (http://en.wikipedia.org/wiki/Duck_typing).
> From the Javascript point of view, an implementation is then just the
> definition of an object that should implement as set of expected methods
> (2 for now), that will be properly documented. The registration of that
> implementation against the server in plexus.xml currently looks like the
> following :
>
> <component>
> <role>org.xwiki.rendering.map.MapProvider</role>
> <role-hint>google</role-hint>
>
> <implementation>org.xwiki.rendering.internal.map.DefaultMapProvider</implementation>
> <instantiation-strategy>singleton</instantiation-strategy>
> <configuration>
> <jsx>XWiki.GoogleMapsJSExtension</jsx>
> <constructor>XWikiGoogleMap</constructor>
> </configuration>
> </component>
>
> As we can see, the MapProvider component is in reality just a simple
> POJO which provides
> - The document name of the JSX page for that implementation
> - The constructor to use for that implementation (the name of the
> duck-typed object). I need that to be able to handle several kind of
> maps on the same document (meaning several JSX map implementations
> loaded). An alternative could be to have a convention for the object
> name, for example the page name of the jsx document.
>
> The main issue I faced while doing this was the loading of the JS
> library needed by the implementations themselves (the call the google
> maps/y! maps libraries). I really did not wanted to have this generated
> by the macro on the server side (even if the URL is retrieved from
> configuration, it would be not very flexible to handle URL parameters,
> for example to upgrade the version used, etc.), so I inspired from a
> trick I've seen used by several libraries : generating this on the
> client side, by the JSX itself, using document.write("<script>..."); I
> agree it is not the nicest thing to have, but I could not find a better
> alternative. Maybe somebody has a better idea for this.
>
>> Anyway, I can understand your point of view!
>>
>> I agree for the other map providers...
>>
>> And your macro would create the div to embed the map also?
>> you would not provide an option so that you can provide tell the macro to
>> use a div you have created somewhere?
>
> Yes, this is possible already. If you precise a container node id in the
> macro parameters, this one will be used, otherwise, one will be created
> for you on the fly.
>
>> Conclusion: write a real macro and let's see if this is not too heavy
>> compared to a simple velocity one :)
>
> Conclusion: I will upload a first patch very soon on JIRA, so that this
> whole idea can be better reviewed :)
> We also have to think about a proper place for new macros. I developed
> this one in the rendering component, but it really don't think it's a
> proper place for it, especially since now there is a "wiki" part. I'm
> thinking about a xwiki-macros component, with components/ and wiki/
> sub-modules. WDYT ?
>
> Regards,
> Jerome.
>>
>>> Regards,
>>> Jerome.
>>>
>>>> regards
>>>> Pascal
>>>>
>>>> On Thu, Oct 30, 2008 at 9:27 AM, Jerome Velociter <[EMAIL PROTECTED]>
>>> wrote:
>>>>> Hello all,
>>>>>
>>>>> I started working on a {{map}} macro
>>>>> (http://jira.xwiki.org/jira/browse/XWIKI-2784).
>>>>> This raise the question of how (or if) we should work when writing
>>>>> macros depending on JS APIs (being here google maps, yahoo maps, etc.).
>>>>>
>>>>> The variants I've envisaged so far :
>>>>>
>>>>> 1a. We write all the needed JavaScript in the macro itself. We do it in
>>>>> Strings we transform in lists of WordBlock + SpaceBlock we append as
>>>>> children of a XMLBlock "script". I find this a little painful and not
>>>>> very natural.
>>>>>
>>>>> 1b. We write all the needed JavaScript in the macro itself. We do it in
>>>>> Strings we pass as content of a html/xhtml macros blocks.
>>>>> 2a. We write most of the JavaScript in a JSX object (for example a sort
>>>>> of facade to some google maps APIs), and only the needed calls in the
>>>>> macro itself (for example the call to load a map in a div element).
>>>>> For the code in the macro, we use the same strategy as 1a, except that
>>>>> there is just one of such XML block, and it's relatively short.
>>>>> The JSX Strategy in 2a/2b has that clear advantage to make it much
>>>>> simpler on the server side, but as a counterpart, the macro needs to be
>>>>> distributed as a xar + jar, while in 1) it's a jar only.
>>>>> 2b. Same as 2a using the strategy in 1b for the part in the macro. This
>>>>> is the way I have my prototype working right now. I admit I don't really
>>>>> know what to think about the fact I'm building macros blocks (a velocity
>>>>> one for the jsx "use" call, and a html one for the javascript call)
>>>>> inside the macro itself. I hope you can tell more about this, and let me
>>>>> know if it's a bad practice.
>>>>>
>>>>> 3. We don't do such macro :) We consider it's not what wiki macro should
>>>>> be and we decide to have such macros only as velocity macros which are
>>>>> much simpler to write in that case. This does not change anything for
>>>>> the wysiwyg users, as far as I understand, but it does for the wiki
>>>>> users.{{map location="Paris, France"}} is much more elegant than
>>>>> {{velocity}}#map("Paris, France"){{/velocity}} ; and is much better too
>>>>> in terms of configuration (in velocity we would need to give values to
>>>>> all parameters, even if we want to use default value for most of them).
>>>>>
>>>>> WDYT ? Are there some variants I did not envisage ?
>>>>>
>>>>> Regards,
>>>>> Jerome.
>>>>> _______________________________________________
>>>>> devs mailing list
>>>>> [email protected]
>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>
>>>> _______________________________________________
>>>> devs mailing list
>>>> [email protected]
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>> _______________________________________________
>>> devs mailing list
>>> [email protected]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> _______________________________________________
>> devs mailing list
>> [email protected]
>> http://lists.xwiki.org/mailman/listinfo/devs
>
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
