30 Oct
2008
30 Oct
'08
9:27 a.m.
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.
31 Oct
31 Oct
5:05 p.m.
New subject: [xwiki-devs] How to best work with JavaScript in Syntax 2.0 macros
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...
regards
Pascal
On Thu, Oct 30, 2008 at 9:27 AM, Jerome Velociter <jerome(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:09 p.m.
New subject: [xwiki-devs] How to best work with JavaScript in Syntax 2.0 macros
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}}
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.
Regards,
Jerome.
regards
Pascal
On Thu, Oct 30, 2008 at 9:27 AM, Jerome Velociter <jerome(a)xwiki.com> 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
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
6:34 p.m.
New subject: [xwiki-devs] How to best work with JavaScript in Syntax 2.0 macros
On Fri, Oct 31, 2008 at 6:09 PM, Jerome Velociter <jerome(a)xwiki.com> wrote:
Pascal Voitot wrote:
yes this is not very nice :)
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}}
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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
regards
Pascal
On Thu, Oct 30, 2008 at 9:27 AM, Jerome Velociter <jerome(a)xwiki.com>
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
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
2 Nov
2 Nov
4:33 p.m.
New subject: [xwiki-devs] How to best work with JavaScript in Syntax 2.0 macros
Hello Pascal, All,
See below
Pascal Voitot wrote:
On Fri, Oct 31, 2008 at 6:09 PM, Jerome Velociter
<jerome(a)xwiki.com> wrote:
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.
Pascal Voitot wrote:
yes this is not very nice :)
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}}
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?
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.
_______________________________________________
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 regards
Pascal
On Thu, Oct 30, 2008 at 9:27 AM, Jerome Velociter <jerome(a)xwiki.com>
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
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
4:35 p.m.
New subject: [xwiki-devs] How to best work with JavaScript in Syntax 2.0 macros
Jerome Velociter wrote:
Hello Pascal, All,
See below
Pascal Voitot wrote:
s/above/below (in the initial mail)
On Fri, Oct 31, 2008 at 6:09 PM, Jerome Velociter
<jerome(a)xwiki.com> wrote:
I tend to agree with your point, this is why I initially emitted the
reserve in point 3. above. Pascal Voitot wrote:
yes this is not very nice :)
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}}
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 :) 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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs regards
Pascal
On Thu, Oct 30, 2008 at 9:27 AM, Jerome Velociter <jerome(a)xwiki.com>
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
> 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
3 Nov
3 Nov
9:07 a.m.
New subject: [xwiki-devs] How to best work with JavaScript in Syntax 2.0 macros
Jerome Velociter wrote:
Hello Pascal, All,
See below
Pascal Voitot wrote:
Done : http://jira.xwiki.org/jira/browse/XWIKI-2784
Jerome.
On Fri, Oct 31, 2008 at 6:09 PM, Jerome Velociter
<jerome(a)xwiki.com> wrote:
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.
Pascal Voitot wrote:
yes this is not very nice :)
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}}
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?
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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Regards,
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs regards
Pascal
On Thu, Oct 30, 2008 at 9:27 AM, Jerome Velociter <jerome(a)xwiki.com>
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
> 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
5 Nov
5 Nov
1:59 a.m.
New subject: [xwiki-devs] How to best work with JavaScript in Syntax 2.0 macros
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 <jerome(a)xwiki.com> wrote:
Hello Pascal, All,
See below
Pascal Voitot wrote:
yes this is not very nice :)
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.
_______________________________________________
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
On Fri, Oct 31, 2008 at 6:09 PM, Jerome Velociter
<jerome(a)xwiki.com>
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}}
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?
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 <jerome(a)xwiki.com>
> 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
> 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
4 Nov
4 Nov
4:54 p.m.
New subject: [xwiki-devs] How to best work with JavaScript in Syntax 2.0 macros
Hi,
On Thu, Oct 30, 2008 at 9:27 AM, Jerome Velociter <jerome(a)xwiki.com> 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 ?
IMO JSX should be a component supporting loading jar/fs resources
files and not only wiki pages. In your case you would ask JSX to use a
provided resource URL (or even better a list of JSXSource containing :
[WIKIJSXSource, URLJSXSource] to first try wiki then the defaut js you
provide to be able to overload it in the wiki).
So I would say :
4. load you js from resource file and insert it as XMLBlock (you don't
need to cut it in Word/SpaceBlock, you just create a "scrip" XMLBlock
and set you whole js as the String content of the XMLBlock) waiting
for JSX to support it.
Regards,
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
5847
days inactive
5853
days old
8 comments
3 participants
participants (3)
-
Jerome Velociter -
Pascal Voitot -
Thomas Mortagne