24 Apr
2008
24 Apr
'08
11:01 a.m.
Dear devs,
In XWS 1.0, I've tried to make the product work with every skin we package
with XE, in addition to XWS own skin ("workspaces"). For this, I placed
several velocity files in the templates/ folder of the product webapp, for
them to be available for every skin (for example, workspace.vm which is
use as a "defaultTemplate" for workspaces home pages, or xwsmacros.vm
which hold workspaces macros). I realized recently it's not proper
solution, as it does alter a directory which is supposed to be common for
every products, and it makes it harder to install properly XWS over an
existing XE, or sharing XWS and XE instances in a XEM context.
Put simple, I could not find a nice way of having both :
1) XWS not being intrusive in the webapp, apart from its skin
2) Workspaces work with every skin
As for now, I consider 1) being more important than 2), and I see more use
cases for it. So for XWS 1.1, I will remove the overriding templates/
folder by moving its velocity files in the workspaces skin. This will then
break point 2).
Are there any other solutions to reconcile both points I didn't see ?
For the future, I suppose we could use UI extensions for this.
Regards,
Jérôme.
24 Apr
24 Apr
3:36 p.m.
Jerome Velociter wrote:
Dear devs,
In XWS 1.0, I've tried to make the product work with every skin we package
with XE, in addition to XWS own skin ("workspaces"). For this, I placed
several velocity files in the templates/ folder of the product webapp, for
them to be available for every skin (for example, workspace.vm which is
use as a "defaultTemplate" for workspaces home pages, or xwsmacros.vm
which hold workspaces macros). I realized recently it's not proper
solution, as it does alter a directory which is supposed to be common for
every products, and it makes it harder to install properly XWS over an
existing XE, or sharing XWS and XE instances in a XEM context.
Put simple, I could not find a nice way of having both :
1) XWS not being intrusive in the webapp, apart from its skin
2) Workspaces work with every skin
As for now, I consider 1) being more important than 2), and I see more use
cases for it. So for XWS 1.1, I will remove the overriding templates/
folder by moving its velocity files in the workspaces skin. This will then
break point 2).
Are there any other solutions to reconcile both points I didn't see ?
Yes, Template Extensions (proposal pending, 30% written already).
However, it will take some time until that will be coded, so it is
something for the future. For now, I'd stick with the altered
/templates/ directory.
For the future, I suppose we could use UI extensions
for this.
Regards,
Jérôme.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
3:52 p.m.
On Apr 24, 2008, at 3:36 PM, Sergiu Dumitriu wrote:
Jerome Velociter wrote:
That currently doesn't work with 1.4...
-Vincent
Dear devs,
In XWS 1.0, I've tried to make the product work with every skin we
package
with XE, in addition to XWS own skin ("workspaces"). For this, I
placed
several velocity files in the templates/ folder of the product
webapp, for
them to be available for every skin (for example, workspace.vm
which is
use as a "defaultTemplate" for workspaces home pages, or xwsmacros.vm
which hold workspaces macros). I realized recently it's not proper
solution, as it does alter a directory which is supposed to be
common for
every products, and it makes it harder to install properly XWS over
an
existing XE, or sharing XWS and XE instances in a XEM context.
Put simple, I could not find a nice way of having both :
1) XWS not being intrusive in the webapp, apart from its skin
2) Workspaces work with every skin
As for now, I consider 1) being more important than 2), and I see
more use
cases for it. So for XWS 1.1, I will remove the overriding templates/
folder by moving its velocity files in the workspaces skin. This
will then
break point 2).
Are there any other solutions to reconcile both points I didn't see ?
Yes, Template Extensions (proposal pending, 30% written already).
However, it will take some time until that will be coded, so it is
something for the future. For now, I'd stick with the altered
/templates/ directory. > For the future, I suppose we could use UI
extensions for this.
>
> Regards,
> Jérôme.
>
25 Apr
25 Apr
9:22 a.m.
On Apr 24, 2008, at 3:36 PM, Sergiu Dumitriu wrote:
You refer to the hardcoded macros.vm lookup by the new velocity engine ?
If so you suggested the ant task that would append xws macros to
/templates/macros.vm at build time, but I must admit I don't like it since
it would make installing XWS manually even harder.
What if we would be able to define foldback paths for filesystem skins ?
Could that be a functionality of the SkinManager component you are
writing, or this has nothing to do ?
Jerome.
Jerome Velociter wrote:
That currently doesn't work with 1.4... Dear devs,
In XWS 1.0, I've tried to make the product work with every skin we
package
with XE, in addition to XWS own skin ("workspaces"). For this, I
placed
several velocity files in the templates/ folder of the product
webapp, for
them to be available for every skin (for example, workspace.vm
which is
use as a "defaultTemplate" for workspaces home pages, or xwsmacros.vm
which hold workspaces macros). I realized recently it's not proper
solution, as it does alter a directory which is supposed to be
common for
every products, and it makes it harder to install properly XWS over
an
existing XE, or sharing XWS and XE instances in a XEM context.
Put simple, I could not find a nice way of having both :
1) XWS not being intrusive in the webapp, apart from its skin
2) Workspaces work with every skin
As for now, I consider 1) being more important than 2), and I see
more use
cases for it. So for XWS 1.1, I will remove the overriding templates/
folder by moving its velocity files in the workspaces skin. This
will then
break point 2).
Are there any other solutions to reconcile both points I didn't see ?
Yes, Template Extensions (proposal pending, 30% written already).
However, it will take some time until that will be coded, so it is
something for the future. For now, I'd stick with the altered
/templates/ directory.
-Vincent
> For the future, I suppose we could use UI
extensions for this.
>
> Regards,
> Jérôme.
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:39 a.m.
Hi Jerome,
On Apr 25, 2008, at 9:22 AM, Jerome Velociter wrote:
I'm not implementing a SkinManager, it needs a lot of other components
first before it's possible (including the new model). I think that
would go in the TemplateManager and not in the SkinManager though.
Right now the velocity renderer code creates one Velocity Engine per
skin and adds templates/macros.vm + skin/<skinname>/macros.vm as
global velocimacros.
We don't currently have a place to let skins define the list of all
their velocimacros.
I don't understand why it's a problem to append your macros during the
build to the templates/macros.vm file on the fly? The user will always
have the already built file...
You could also maybe use the velocity import feature to have several
files if you prefer
(http://www.jajakarta.org/velocity/velocity-1.2/docs/user-guide.html#Include
)
That said, one other solution, while waiting for a proper
TemplateManager would be to add configuration options to the
VelocityEngine component so that you can configure a list of
velocimacro templates instead of hardcoding it (which isn't nice
anyway). That should be quite easy to do. However the only problem is
that I need to know how you can override the default config during the
XWS build. Right now I haven't written the configuration component yet
so our config is in components.xml. I'm sure there's a way but I need
to ask how to do it.
Let's talk about this today together. I can whip up something pretty
quickly if needed.
Thanks
-Vincent
On Apr 24, 2008, at 3:36 PM, Sergiu Dumitriu wrote:
You refer to the hardcoded macros.vm lookup by the new velocity
engine ?
If so you suggested the ant task that would append xws macros to
/templates/macros.vm at build time, but I must admit I don't like it
since
it would make installing XWS manually even harder.
What if we would be able to define foldback paths for filesystem
skins ?
Could that be a functionality of the SkinManager component you are
writing, or this has nothing to do ? Jerome Velociter wrote:
That currently doesn't work with 1.4... Dear devs,
In XWS 1.0, I've tried to make the product work with every skin we
package
with XE, in addition to XWS own skin ("workspaces"). For this, I
placed
several velocity files in the templates/ folder of the product
webapp, for
them to be available for every skin (for example, workspace.vm
which is
use as a "defaultTemplate" for workspaces home pages, or
xwsmacros.vm
which hold workspaces macros). I realized recently it's not proper
solution, as it does alter a directory which is supposed to be
common for
every products, and it makes it harder to install properly XWS over
an
existing XE, or sharing XWS and XE instances in a XEM context.
Put simple, I could not find a nice way of having both :
1) XWS not being intrusive in the webapp, apart from its skin
2) Workspaces work with every skin
As for now, I consider 1) being more important than 2), and I see
more use
cases for it. So for XWS 1.1, I will remove the overriding
templates/
folder by moving its velocity files in the workspaces skin. This
will then
break point 2).
Are there any other solutions to reconcile both points I didn't
see ?
Yes, Template Extensions (proposal pending, 30% written already).
However, it will take some time until that will be coded, so it is
something for the future. For now, I'd stick with the altered
/templates/ directory. >
>>> For the future, I suppose we could use UI extensions for this.
>>>
>>> Regards,
>>> Jérôme.
>>>
9:47 a.m.
Hi Jerome,
On Apr 25, 2008, at 9:22 AM, Jerome Velociter wrote:
I'm not implementing a SkinManager, it needs a lot of other components
first before it's possible (including the new model). I think that
would go in the TemplateManager and not in the SkinManager though.
Right now the velocity renderer code creates one Velocity Engine per
skin and adds templates/macros.vm + skin/<skinname>/macros.vm as
global velocimacros.
We don't currently have a place to let skins define the list of all
their velocimacros.
I don't understand why it's a problem to append your macros during the
build to the templates/macros.vm file on the fly? The user will always
have the already built file...
Just for the wild ones willing to install XWS over an existing XE or XEM
webapp :) You are right, even those will have the built file, but they
will need to erase their own one (which they have possibly modified).
On Apr 24, 2008, at 3:36 PM, Sergiu Dumitriu wrote:
You refer to the hardcoded macros.vm lookup by the new velocity
engine ?
If so you suggested the ant task that would append xws macros to
/templates/macros.vm at build time, but I must admit I don't like it
since
it would make installing XWS manually even harder.
What if we would be able to define foldback paths for filesystem
skins ?
Could that be a functionality of the SkinManager component you are
writing, or this has nothing to do ? Jerome Velociter wrote:
> Dear devs,
>
> In XWS 1.0, I've tried to make the product work with every skin we
> package
> with XE, in addition to XWS own skin ("workspaces"). For this, I
> placed
> several velocity files in the templates/ folder of the product
> webapp, for
> them to be available for every skin (for example, workspace.vm
> which is
> use as a "defaultTemplate" for workspaces home pages, or
> xwsmacros.vm
> which hold workspaces macros). I realized recently it's not proper
> solution, as it does alter a directory which is supposed to be
> common for
> every products, and it makes it harder to install properly XWS over
> an
> existing XE, or sharing XWS and XE instances in a XEM context.
>
> Put simple, I could not find a nice way of having both :
>
> 1) XWS not being intrusive in the webapp, apart from its skin
> 2) Workspaces work with every skin
>
> As for now, I consider 1) being more important than 2), and I see
> more use
> cases for it. So for XWS 1.1, I will remove the overriding
> templates/
> folder by moving its velocity files in the workspaces skin. This
> will then
> break point 2).
>
> Are there any other solutions to reconcile both points I didn't
> see ?
Yes, Template Extensions (proposal pending, 30% written already).
However, it will take some time until that will be coded, so it is
something for the future. For now, I'd stick with the altered
/templates/ directory.
That currently doesn't work with 1.4... You could also maybe use the velocity import feature
to have several
files if you prefer
(http://www.jajakarta.org/velocity/velocity-1.2/docs/user-guide.html#Include
)
Yes, that sound better.
That said, one other solution, while waiting for a proper
TemplateManager would be to add configuration options to the
VelocityEngine component so that you can configure a list of
velocimacro templates instead of hardcoding it (which isn't nice
anyway). That should be quite easy to do. However the only problem is
that I need to know how you can override the default config during the
XWS build. Right now I haven't written the configuration component yet
so our config is in components.xml. I'm sure there's a way but I need
to ask how to do it.
Let's talk about this today together. I can whip up something pretty
quickly if needed.
Ok, thanks a lot.
Jerome.
Thanks
-Vincent
>
>>> For the future, I suppose we could use UI extensions for this.
>>>
>>> Regards,
>>> Jérôme.
>>>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5992
days inactive
5993
days old
5 comments
3 participants
participants (3)
-
Jerome Velociter -
Sergiu Dumitriu -
Vincent Massol