Hello,
just have seen your patch... can't test it now...
Seems quite clever at first sight. Just try to make as simple as possible
for end-users.
Just some remarks...
concerning the loading of the map libraries, you will do it with
document.write("<script>...") in the JSX. Not very nice but what other
solution? On my side, as I explained, I modified JSX to be able to add an
external URL <script> in the page header... I found it elegant but I'm not
sure you agree with that :)
Finally, where is defined the URL of the map library including the API key
and possible version?
As soon as my test environment is back, I will test your patch!
regards
Pascal
On Sun, Nov 2, 2008 at 4:33 PM, Jerome Velociter <[EMAIL PROTECTED]> 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.
> 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
