Rallying the troops! Let's kick 3.1 into high gear!

[Howard Lewis Ship <hl...@gmail.com>]

It's a new year and it's time to get Tapestry 3.1 really rolling.  I'm
concerned that 3.1 will drag on as long as 3.0 did (well over a year).

I've been getting a lot of work done in fits and starts,  and its
looking likely that I have a corporate sponsor for doing a big burst
of focused work ... adding Portlet support.

I think its very much time to start getting organized, either here (or
better yet) on the Wiki.

The 3.1 DTDs are very stable at this point; that was one of my
concerns with having too many cooks; I didn't want to deal with
maintenance of dozens of XML files for each change to the DTD. 
Although a couple of DTD changes could still happen, they would have
very localized effects.

The APIs are, I believe, fairly stable.  I'm continuing to do
refactorings all over the place, but they generally won't affect
component code.  Everything is hidden under umpteen layers of
abstractions, just as it should be.

What I'd like to see is a kind of signup sheet, listing what people
want to get done for 3.1, and when they think they'll do the work.

I'm afraid that some combination of changes broke Table and Tree (!).
I'm not exactly sure why.  Components that made heavy use of the
custom direction are the ones most likely affected by the transition
from 3.0 to 3.1.

My preferred roadmap for Tapestry would be a solid beta by May, at
which point features will lock down.  I'd like to see a GA as soon as
possible after that, perhaps June. Anything non-critical can wait for
Tapestry 3.1.1 or 3.2.

-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

Re: paramter services for links (3.1)

[Howard Lewis Ship <hl...@gmail.com>]

Yes, you're right on it; the tapestry.url.LinkFactory will be extended
to ask all the property persistence stategies to contribute their
query parameters. And all of those other options are certainly on the
table!  I also need to do some work on Form to deal with potential
name collisions between the query parameters generated by the
services, and those it generates.

I think there will be several "flavors" of client persistence,
controlling whether values "persist" just while you are on the same
page, or whether they can survive navigation around the application.

There's also the question about whether the external service, for
example, should allow properties to be persisted in its URLs.


On Sat, 8 Jan 2005 23:43:56 +0200, Mind Bridge <mi...@yahoo.com> wrote:
> Hi,
> 
> Just to mention that the way the property stratergies are implemented
> (PropertyPersistenceStrategy, etc) is really nice and very flexible.
> 
> In order to have a ClientPropertyPersistenceStrategy (or a
> URLPropertyPersistenceStrategy, rather), the properties need to be a part of
> every link that is generated. Do you have any plans as to how to do that?
> 
> One way to do it is to have a set of services that contribute parameters to
> the URL and are invoked every time a new one is created. The usual suspect
> to do this is the LinkFactory implementation, I guess. A similar approach
> opens the door for a number of services addressing different needs of the
> application, such as storing the properties with URL strategy, keeping a
> counter to notice when the Back button has been used, keeping a stack of
> invocations when a call transition has been made, etc.
> 
> What do you think? Any thoughts?
> 
> ----- Original Message -----
> From: "Howard Lewis Ship" <hl...@gmail.com>
> To: "Tapestry development" <ta...@jakarta.apache.org>
> Sent: Saturday, January 08, 2005 6:02 PM
> Subject: Rallying the troops! Let's kick 3.1 into high gear!
> 
> > It's a new year and it's time to get Tapestry 3.1 really rolling.  I'm
> > concerned that 3.1 will drag on as long as 3.0 did (well over a year).
> >
> > I've been getting a lot of work done in fits and starts,  and its
> > looking likely that I have a corporate sponsor for doing a big burst
> > of focused work ... adding Portlet support.
> >
> > I think its very much time to start getting organized, either here (or
> > better yet) on the Wiki.
> >
> > The 3.1 DTDs are very stable at this point; that was one of my
> > concerns with having too many cooks; I didn't want to deal with
> > maintenance of dozens of XML files for each change to the DTD.
> > Although a couple of DTD changes could still happen, they would have
> > very localized effects.
> >
> > The APIs are, I believe, fairly stable.  I'm continuing to do
> > refactorings all over the place, but they generally won't affect
> > component code.  Everything is hidden under umpteen layers of
> > abstractions, just as it should be.
> >
> > What I'd like to see is a kind of signup sheet, listing what people
> > want to get done for 3.1, and when they think they'll do the work.
> >
> > I'm afraid that some combination of changes broke Table and Tree (!).
> > I'm not exactly sure why.  Components that made heavy use of the
> > custom direction are the ones most likely affected by the transition
> > from 3.0 to 3.1.
> >
> > My preferred roadmap for Tapestry would be a solid beta by May, at
> > which point features will lock down.  I'd like to see a GA as soon as
> > possible after that, perhaps June. Anything non-critical can wait for
> > Tapestry 3.1.1 or 3.2.
> >
> > --
> > Howard M. Lewis Ship
> > Independent J2EE / Open-Source Java Consultant
> > Creator, Jakarta Tapestry
> > Creator, Jakarta HiveMind
> >
> > Professional Tapestry training, mentoring, support
> > and project work.  http://howardlewisship.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 1/6/2005
> >
> >
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 1/6/2005
> 
> 


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

paramter services for links (3.1)

[Mind Bridge <mi...@yahoo.com>]

Hi,

Just to mention that the way the property stratergies are implemented
(PropertyPersistenceStrategy, etc) is really nice and very flexible.

In order to have a ClientPropertyPersistenceStrategy (or a
URLPropertyPersistenceStrategy, rather), the properties need to be a part of
every link that is generated. Do you have any plans as to how to do that?

One way to do it is to have a set of services that contribute parameters to
the URL and are invoked every time a new one is created. The usual suspect
to do this is the LinkFactory implementation, I guess. A similar approach
opens the door for a number of services addressing different needs of the
application, such as storing the properties with URL strategy, keeping a
counter to notice when the Back button has been used, keeping a stack of
invocations when a call transition has been made, etc.

What do you think? Any thoughts?

----- Original Message ----- 
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Saturday, January 08, 2005 6:02 PM
Subject: Rallying the troops! Let's kick 3.1 into high gear!


> It's a new year and it's time to get Tapestry 3.1 really rolling.  I'm
> concerned that 3.1 will drag on as long as 3.0 did (well over a year).
>
> I've been getting a lot of work done in fits and starts,  and its
> looking likely that I have a corporate sponsor for doing a big burst
> of focused work ... adding Portlet support.
>
> I think its very much time to start getting organized, either here (or
> better yet) on the Wiki.
>
> The 3.1 DTDs are very stable at this point; that was one of my
> concerns with having too many cooks; I didn't want to deal with
> maintenance of dozens of XML files for each change to the DTD.
> Although a couple of DTD changes could still happen, they would have
> very localized effects.
>
> The APIs are, I believe, fairly stable.  I'm continuing to do
> refactorings all over the place, but they generally won't affect
> component code.  Everything is hidden under umpteen layers of
> abstractions, just as it should be.
>
> What I'd like to see is a kind of signup sheet, listing what people
> want to get done for 3.1, and when they think they'll do the work.
>
> I'm afraid that some combination of changes broke Table and Tree (!).
> I'm not exactly sure why.  Components that made heavy use of the
> custom direction are the ones most likely affected by the transition
> from 3.0 to 3.1.
>
> My preferred roadmap for Tapestry would be a solid beta by May, at
> which point features will lock down.  I'd like to see a GA as soon as
> possible after that, perhaps June. Anything non-critical can wait for
> Tapestry 3.1.1 or 3.2.
>
> -- 
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work.  http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 1/6/2005
>
>



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 1/6/2005


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

Re: Rallying the troops! Let's kick 3.1 into high gear!

[Mind Bridge <mi...@yahoo.com>]

Hi Howard,

I am afraid there have been consistently some problems (relatively small
ones) with the build that is checked in. For example, some libraries were
not on ibiblio, even though the build was trying to download them. Earlier
the unit tests were failing and it was hard to run the workbench at all.
Currently, the Defense class is missing, probably due to an incorrect
Hivemind version, and the code cannot compile at all. The Eclipse classpath
also contains absolute paths to some directories that are probably specific
only to your computer.

Most of those problems have been easy to solve, but do hamper greatly any
additions we would like to make. May I ask you to try to get a build from
CVS in a separate location, build it, and make the necessary adjustments to
ensure that it works identically to the version that you use for
development?


----- Original Message ----- 
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Saturday, January 08, 2005 6:02 PM
Subject: Rallying the troops! Let's kick 3.1 into high gear!


> It's a new year and it's time to get Tapestry 3.1 really rolling.  I'm
> concerned that 3.1 will drag on as long as 3.0 did (well over a year).
>
> I've been getting a lot of work done in fits and starts,  and its
> looking likely that I have a corporate sponsor for doing a big burst
> of focused work ... adding Portlet support.
>
> I think its very much time to start getting organized, either here (or
> better yet) on the Wiki.
>
> The 3.1 DTDs are very stable at this point; that was one of my
> concerns with having too many cooks; I didn't want to deal with
> maintenance of dozens of XML files for each change to the DTD.
> Although a couple of DTD changes could still happen, they would have
> very localized effects.
>
> The APIs are, I believe, fairly stable.  I'm continuing to do
> refactorings all over the place, but they generally won't affect
> component code.  Everything is hidden under umpteen layers of
> abstractions, just as it should be.
>
> What I'd like to see is a kind of signup sheet, listing what people
> want to get done for 3.1, and when they think they'll do the work.
>
> I'm afraid that some combination of changes broke Table and Tree (!).
> I'm not exactly sure why.  Components that made heavy use of the
> custom direction are the ones most likely affected by the transition
> from 3.0 to 3.1.
>
> My preferred roadmap for Tapestry would be a solid beta by May, at
> which point features will lock down.  I'd like to see a GA as soon as
> possible after that, perhaps June. Anything non-critical can wait for
> Tapestry 3.1.1 or 3.2.
>
> -- 
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work.  http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 1/6/2005
>
>



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 1/6/2005


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org