Re: tiles 2 + velocity integration

[Nathan Bubna]

Hi Sergey,

This is great!  A Tiles2Tool has been on my wish-i-had-the-time-todo
list ever since work on Tiles 2 began, but life is nuts, ya know?
Anyway, i just took a quick look through the code.  It looks like key
pieces are there; though it would take a little effort to adapt for
work outside of Spring (e.g. in plain VelocityTools 2).

If none of this finds a home in Spring or Tiles, i would be interested
in bringing some of it over into VelocityTools.  I've cross-posted
this message to the dev@velocity list in case anyone there is
interested.

I don't have time to look more today, but i will next week.  Expect to
hear more from me! :)

-nathan

On Fri, Jun 27, 2008 at 1:16 PM, Sergey Zolotaryov <anydoby@...> wrote:
> Hello.
>
> I have created a little plugin to integrate Velocity with Tiles2. I
> use it for my site with Spring MVC, but I think it might be useful for
> other users even those not using Spring.
>
> Here is the link http://anydoby.com/velocity. If you are interested it
> would be an honor for me contribute to the ASF.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Antonio Petrelli-3]

First of all, sorry for crossposting again :-)

2008/6/28 Nathan Bubna <nbubna@...>:
> If none of this finds a home in Spring or Tiles, i would be interested
> in bringing some of it over into VelocityTools.

First of all, what is the best place for such a plugin?
IMHO it is Tiles, since we want to treat view technologies in the same
way (JSP, Velocity, FreeMarker are the same in front of Tiles :-D ).
OTOH there is already a Velocity Tool for Tiles 1.
Well, I can't decide :-)

Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Nathan Bubna]

On Fri, Jun 27, 2008 at 11:45 PM, Antonio Petrelli
<antonio.petrelli@...> wrote:

> First of all, sorry for crossposting again :-)
>
> 2008/6/28 Nathan Bubna <nbubna@...>:
>> If none of this finds a home in Spring or Tiles, i would be interested
>> in bringing some of it over into VelocityTools.
>
> First of all, what is the best place for such a plugin?
> IMHO it is Tiles, since we want to treat view technologies in the same
> way (JSP, Velocity, FreeMarker are the same in front of Tiles :-D ).
> OTOH there is already a Velocity Tool for Tiles 1.
> Well, I can't decide :-)

VelocityTools 2 is extremely flexible at this point.  Including a tool
that lives in a separate library is very easy.  Tiles could even
include a tools.xml in its jar with the TilesTool configuration and
most standard VelocityTools 2 users would automatically pick up the
tool if they just add the tiles jar to their app.   I've worked hard
to make it easy for tools to live elsewhere and have no (or precious
few) ties to VelocityTools' release schedule.   That way the tools can
stay in sync with the APIs that they front.   Given that and the fact
that we're already supporting other view technologies in Tiles, i
think it would fit best here.  I will, of course, help out with that
as much as possible.

Now, i realize that Sergey's code is for VelocityTools 1.x, but i do
think we should target VelocityTools 2.  Tools 2.0-beta2 should be out
next week, and i don't intend for 2.0 GA to be far behind.   Also,
given the flexibility of Tools 2, it actually is pretty easy to have a
1.x compatible version extend the 2.x version.

What do you think?

> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Antonio Petrelli-3]

2008/6/28 Nathan Bubna <nbubna@...>:
> VelocityTools 2 is extremely flexible at this point.  Including a tool
> that lives in a separate library is very easy.  Tiles could even
> include a tools.xml in its jar with the TilesTool configuration and
> most standard VelocityTools 2 users would automatically pick up the
> tool if they just add the tiles jar to their app.

In fact I was thinking of a separate optional JAR, just like the
"tiles-jsp.jar". Is it possible?

> Given that and the fact
> that we're already supporting other view technologies in Tiles, i
> think it would fit best here.  I will, of course, help out with that
> as much as possible.

OK, remember that you are a PMC member of Tiles, too ;-)

> Now, i realize that Sergey's code is for VelocityTools 1.x, but i do
> think we should target VelocityTools 2.  Tools 2.0-beta2 should be out
> next week, and i don't intend for 2.0 GA to be far behind.

+1 to use Tools 2, independently from your release schedule.

>  Also,
> given the flexibility of Tools 2, it actually is pretty easy to have a
> 1.x compatible version extend the 2.x version.

I think that retrocompatibility depends on volunteers effort: if
someone of us really *wants* to use Tools 1, then OK.

> What do you think?

I think we have left one important point: the codebase of the work
made by Sergey lives outside of Apache, so probably an IP clearance
process is necessary.

Sergey, if you still want to contribute, do you simply want to donate
your code (with obvious recognition in SVN logs and contributor page),
or do you want to collaborate to create a Tiles 2 + VelocityTools 2
module?
Either way, your contribute will really be appreciated :-)

Thanks
Antonio

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Nathan Bubna]

since it looks like Tiles will be the proper home, this will be my
last cross-post to dev@velocity.  if anyone there wants to continue
following this, c'mon over to dev@tiles. :)

On Sat, Jun 28, 2008 at 11:46 AM, Antonio Petrelli
<antonio.petrelli@...> wrote:
> 2008/6/28 Nathan Bubna <nbubna@...>:
>> VelocityTools 2 is extremely flexible at this point.  Including a tool
>> that lives in a separate library is very easy.  Tiles could even
>> include a tools.xml in its jar with the TilesTool configuration and
>> most standard VelocityTools 2 users would automatically pick up the
>> tool if they just add the tiles jar to their app.
>
> In fact I was thinking of a separate optional JAR, just like the
> "tiles-jsp.jar". Is it possible?

yes, that would be excellent.

>> Given that and the fact
>> that we're already supporting other view technologies in Tiles, i
>> think it would fit best here.  I will, of course, help out with that
>> as much as possible.
>
> OK, remember that you are a PMC member of Tiles, too ;-)

i remember :)

>> Now, i realize that Sergey's code is for VelocityTools 1.x, but i do
>> think we should target VelocityTools 2.  Tools 2.0-beta2 should be out
>> next week, and i don't intend for 2.0 GA to be far behind.
>
> +1 to use Tools 2, independently from your release schedule.
>
>>  Also,
>> given the flexibility of Tools 2, it actually is pretty easy to have a
>> 1.x compatible version extend the 2.x version.
>
> I think that retrocompatibility depends on volunteers effort: if
> someone of us really *wants* to use Tools 1, then OK.
>
>> What do you think?
>
> I think we have left one important point: the codebase of the work
> made by Sergey lives outside of Apache, so probably an IP clearance
> process is necessary.

agreed.  though if we're not bring the spring integration code along,
there's just a few classes we'd adapt the code from.  i suspect a JIRA
attachment with the proper box clicked and a CLA from Sergey should
probably suffice.  it appears that he is the sole author and copyright
owner.  is that right, Sergey?

> Sergey, if you still want to contribute, do you simply want to donate
> your code (with obvious recognition in SVN logs and contributor page),
> or do you want to collaborate to create a Tiles 2 + VelocityTools 2
> module?

yep, it's your contribution, don't let us run the whole discussion here. :)

> Either way, your contribute will really be appreciated :-)

+1!

> Thanks
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...