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 :)
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?
Conclusion: write a real macro and let's see if this is not too heavy
compared to a simple velocity one :)
> 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
