Richard Lewis-Shell: +1 (binding)
On 3/21/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
>
> Brian K. Wallace is an established presence on the Tapestry user and
> developer mailing list. He's answers questions on the user list,
> participates in design discussions and
Richard Lewis-Shell: +1 (binding)
On 3/11/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
>
> Andreas has been a very active tapestry user for a long time now, as well
> as
> more or less taking the lead role lately on the tacos project. I've been
> very impressed with his
Richard Lewis-Shell: +1 (binding)
On 1/31/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
>
> Below is the final text of the vote; for the moment, I've pencilled in
> myself as the chair, as no one else was in a position to take that
> responsibility. If you disagree, vo
Richard Lewis-Shell: +1 (binding)
On 12/31/05, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
>
> I think 4.0 is ready for a wider release and a new release
> announcement to ring in 2006. I know I'm anxious to start putting
> together 4.1 features. The most critical missi
Richard Lewis-Shell: +1 (binding)
Howard Lewis Ship wrote:
> By the time this vote ends, we'll have some kind of fix for
> TAPESTRY-724. I think, with that, Tapestry 4.0 is ready for prime
> time. We've already had the discussion of outstanding bugs needing
> fixing. I t
Richard Lewis-Shell: +1 (binding)
Howard Lewis Ship wrote:
Kent Tong has been a great booster for Tapestry over the last year or
two; not only has he been a constant presense on the mailing list,
mentoring new and experienced users, as well as contributing bugs and
patches ... but he's wr
Richard Lewis-Shell: +1 (binding)
Howard Lewis Ship wrote:
Jesse Kuhnert has been doing some outstanding work with Tacos
(http://tacos.sf.net), powerful Ajax components for Tapestry.
Further, he's been very active on the mailing lists, providing support
to new users and to Tacos users
I too say deprecate.
Geoff Longman wrote:
Umm, they still work right? Pls tell me they still work. Some of us
have very large Tap 3 apps and if we don't have to port every page to
the new validation scheme at once that would be very nice.
I say deprecate.
Geoff
On 9/12/05, David Solis <[EMAIL
Richard Lewis-Shell: +1 (binding)
Howard Lewis Ship wrote:
As per the ongoing discussion, this is a vote to introduce a new
procedure: regular weekly beta releases until Tapestry 4.0 is ready
for release. I will take primary responsibility for producing the
release and the release announcements
+1
Howard Lewis Ship wrote:
I'm quite willing to crank out a new beta release every weekend for
the next few weeks ... but running a vote for each one is time
consuming and boring. How about a general vote to release on a weekly
basis until we vote for an RC candidate?
---
I would prefer the reverse - move the other renderers out of contrib and
into org.apache.tapestry.link. I don't like 'contrib'. It feels
somehow second-class to me, and I'd generally like to see code in
contrib either dumped, or moved to the framework proper.
Paul Ferraro wrote:
Would anyone
I prefer them to be errors. Warnings are too easy to ignore, even when
there are only a few of them...
Paul Ferraro wrote:
But they are not errors... I'd rather be able to easily identify
compilation errors than identify warnings.
e.g. I had to revert the compiler warning settings so that I c
Richard Lewis-Shell: +1
Howard Lewis Ship wrote:
Release early; release often. Lots of good fixes here, and I like
releasing a beta every week or so.
Howard M. Lewis Ship: +1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Richard Lewis-Shell: +1
Howard Lewis Ship wrote:
Since we've found and fixed a couple of real show-stopper bugs in
beta-3, and its been a couple of weeks, I'd like to release beta-4.
Howard M. Lewis Ship: +1
--
Seems like a good idea to me. Do we have an agreed on definition of
what 'beta' means? We decided this was version 4 because it was a big
change, and keeping backwards compatability was not always going to be
possible. I see no need to cling to this confusing/frustrating part of
Tapestry in
Richard Lewis-Shell: +1 (binding)
Howard Lewis Ship wrote:
OK ... this discussion has gone on long enough. I'm willing to strip
out the default-binding stuff and replace it with a simpler approach.
Attributes will be intepreted as literals (unless prefixed) in the
template, and as
Sold!
This is the best argument so far (IMO). Informal bindings HAVE to be
literal in templates, which means only confusion if formal parameters in
the template have ANY other default.
Making specification bindings use literal by default will just be
painful to work with (too many "ognl:"s)
http://jakarta.apache.org/site/decisions.html
Kevin Menard wrote:
Pardon my ignorance, but how does the whole voting thing work anyway?
Do only developers get to vote? Are the votes just -1, 0, +1?
Thanks,
Kevin
Howard Lewis Ship wrote:
OK ... this discussion has gone on long enough. I'm w
Fantastic work (as always)...
Richard Lewis-Shell: +1 (binding)
Howard Lewis Ship wrote:
Things have been cranking along, and we have a number of important
fixes out there, and likely more by the time this vote completes.
Howard M. Lewis Ship: +1
I
appreciate that there is an ASF directive to move by the end of the
year, but I think we should wait till nearer the end of the year.
Richard Lewis-Shell: -1
Richard Lewis-Shell wrote:
My preference would be to wait until 4.0 final is out, and IDE support
improves.
Richard Lewis-Shel
Richard Lewis-Shell: +1
Howard Lewis Ship wrote:
Release early, release often. Let's do a short vote and release
beta-2 as soon as possible.
Howard M. Lewis Ship: +1
-
To unsubscribe, e-mail: [EMAIL PROTECTED
My preference would be to wait until 4.0 final is out, and IDE support
improves.
Richard Lewis-Shell: -0
Richard Lewis-Shell wrote:
Can someone with subversion experience comment on the level of IDE
integration subversion enjoys, especially with Eclipse? If it's not
going to be any h
Can someone with subversion experience comment on the level of IDE
integration subversion enjoys, especially with Eclipse? If it's not
going to be any harder to use via IDEs than CVS right now, then I'll be +0.
Richard
Howard Lewis Ship wrote:
Worked great for HiveMind !
Howard M. Lewis Shi
Richard Lewis-Shell: +1 (binding)
Howard Lewis Ship wrote:
I know this is unusual, but I'd like to make a vote pending some other
developments. I'm anxious to announce beta-1 when I'm at JavaOne.
There are a couple of changes "in the queue" by various committers; I
speak. I felt
inspiried this afternoon. It does mean compiling on JDK 1.5 to target
JDK 1.1, and it also means we can't use commons-lang anymore (it has a
package name thats illegal), so goodbye EnumPropertySelectionModel.
On 6/8/05, Richard Lewis-Shell <[EMAIL PROTECTED]> wrote:
sort of conditional compilation for the annotations.
Richard
Ron Piterman wrote:
So why not vote on adding it as an (unmature) extention to the tapestry
project?
ציטוט Richard Lewis-Shell:
Hi,
I think we should add annotation support to Tapestry 4. The initial
hard work has already been
Hi,
I think we should add annotation support to Tapestry 4. The initial
hard work has already been done by Joni
(http://paloalto.laughingpanda.com/mediawiki/index.php/Tapestry_Annotations),
so this would mostly be a matter of merging his work (which has been
deliberately compatibly licensed
tion of Resource to
an AssetFactory that can provide a matching IAsset, from which a URL
can be created. I'll look into it.
On 5/21/05, Richard Lewis-Shell <[EMAIL PROTECTED]> wrote:
I'm getting another error from the workbench. This time it's:
Unable to instantiate com
Richard Lewis-Shell: -1 (binding)
It is not clear to me that we have exhausted other possibilities to
reduce confusion. Removing the feature seems pretty heavy handed. If
it was deemed that defaults were not so good for the framework, then an
alternative idea would be to make all framework
, including
informal ones, were literal unless otherwise indicated. Some users have
taken to *always* using a binding prefix - so it appears that this
feature is not entirely successful since it's intent was to save
keystrokes. Thoughts?
Paul
Richard Lewis-Shell (JIRA) wrote:
[
[
http://issues.apache.org/jira/browse/TAPESTRY-336?page=comments#action_66425 ]
Richard Lewis-Shell commented on TAPESTRY-336:
--
I am not sure this is a good idea. All the time of time I have used tag I've
used it to select a real o
I'm getting another error from the workbench. This time it's:
Unable to instantiate component Home/$Border: Could not find a strategy
instance for class org.apache.hivemind.util.ContextResource.
component: [EMAIL PROTECTED]/$Border]
location: context:/Home.html, line 1
1
2
en thinking about this too; including a deprecation service that
would log the deprecation warnings ... but just once, so you don't get
flooded.
On 5/14/05, Jamie Orchard-Hays <[EMAIL PROTECTED]> wrote:
I like this idea. It would definitely be useful.
Jamie
On May 14, 2005, at 5:15 AM,
The "good reason" was probably one of compatibility/consistency with the
(Bother link components.
(B
(BNick Westgate wrote:
(B> Hi.
(B>
(B> A minor issue this, but I'm emboldened by the LinkSubmit jira mails.
(B>
(B> LinkSubmit renders as text when disabled, thus losing informal
(B> para
g the underlying JIRA database directly.
Paul
Richard Lewis-Shell wrote:
There's something weird with our JIRA user accounts - they appear to
be duplicated. Howard commented to this effect when trying to give me
access to JIRA. Erik, Paul, and myself show up twice in the assign
users drop-down
There's something weird with our JIRA user accounts - they appear to be
duplicated. Howard commented to this effect when trying to give me
access to JIRA. Erik, Paul, and myself show up twice in the assign
users drop-down list. Any ideas on how to fix?
Richard
Richard Lewis-Shell
[ http://issues.apache.org/jira/browse/TAPESTRY-325?page=all ]
Richard Lewis-Shell resolved TAPESTRY-325:
--
Resolution: Fixed
Fix Version: 4.0
> Allow deferred listener for LinkSub
[ http://issues.apache.org/jira/browse/TAPESTRY-326?page=all ]
Richard Lewis-Shell resolved TAPESTRY-326:
--
Resolution: Fixed
Fix Version: 4.0
> Listener parameters for form submitting compone
[ http://issues.apache.org/jira/browse/TAPESTRY-325?page=all ]
Richard Lewis-Shell reassigned TAPESTRY-325:
Assign To: Richard Lewis-Shell (was: Richard Lewis-Shell)
> Allow deferred listener for LinkSub
I don't much like this idea (-1). I agree that we don't need yet
another way of declaring a component in a template, especially one that
is completely different to the existing templating syntax. What
happened to "less is more"? This feels like "more is less" to me :-(
Richard
Howard M. Lewi
[
http://issues.apache.org/jira/browse/TAPESTRY-306?page=comments#action_65388 ]
Richard Lewis-Shell commented on TAPESTRY-306:
--
Looking at the 4.0 code, Form.getName() will include a call to getId() (for
direct service anyway). getId
Hi,
I am thinking it would be useful to add support to Tapestry for
deprecating components, so that we can provide a clear migration path
for changing components. It can imagine it would be useful to be able
to deprecate an entire component and/or individual component parameters,
and have Tape
[ http://issues.apache.org/jira/browse/TAPESTRY-306?page=all ]
Richard Lewis-Shell updated TAPESTRY-306:
-
Fix Version: 4.0
> LinkSubmit doesn't respect Form's DOM id
>
>
>
[ http://issues.apache.org/jira/browse/TAPESTRY-306?page=all ]
Richard Lewis-Shell reassigned TAPESTRY-306:
Assign To: Richard Lewis-Shell
> LinkSubmit doesn't respect Form's DOM id
>
is Ship <[EMAIL PROTECTED]> wrote:
When was the last time you got from head? Also, I'm running using a Jetty
Launch Config inside Eclipse ... I'll try using Ant in a moment.
On 5/13/05, Richard Lewis-Shell <[EMAIL PROTECTED] > wrote:
Is the workbench from HEAD working for yo
[ http://issues.apache.org/jira/browse/TAPESTRY-325?page=all ]
Richard Lewis-Shell reassigned TAPESTRY-325:
Assign To: Richard Lewis-Shell
planning on refactoring Submit and LinkSubmit to share deferred listener +
listener parameter code
Is the workbench from HEAD working for you guys? It's not for me -
appears the ValidField javascript is broken. The Fields tab doesn't
work properly: the fields don't validate - neither client nor server
side, and the LinkSubmit doesn't work (I think because the javascript is
generally broken
[
http://issues.apache.org/jira/browse/TAPESTRY-306?page=comments#action_65281 ]
Richard Lewis-Shell commented on TAPESTRY-306:
--
What browsers/environments does this effect?
Can you attach a patch, or explain the trivial fix
[ http://issues.apache.org/jira/browse/TAPESTRY-326?page=all ]
Richard Lewis-Shell reassigned TAPESTRY-326:
Assign To: Richard Lewis-Shell
> Listener parameters for form submitting compone
Richard Lewis-Shell: +1 (binding)
Howard Lewis Ship wrote:
Although it hasn't been long since alpha-2, I'd like to release the
next alpha of Tapestry 4.0. Why? A few things have settled down, some
bugs have been fixed, a few really key features have been added, and I
think the Portlet
Listener parameters for form submitting components
--
Key: TAPESTRY-326
URL: http://issues.apache.org/jira/browse/TAPESTRY-326
Project: Tapestry
Type: Improvement
Versions: 4.0
Reporter: Richard Lewis-Shell
Allow deferred listener for LinkSubmit
--
Key: TAPESTRY-325
URL: http://issues.apache.org/jira/browse/TAPESTRY-325
Project: Tapestry
Type: Improvement
Components: Framework
Versions: 4.0
Reporter: Richard Lewis
Hi,
Can someone here give me permissions to assign/resolve issues etc in
JIRA for Tapestry? My userid is rlewisshell.
Richard
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Ignore the suggestion to also incorporate this into ActionLink - this
really only makes sense for components with deferable listeners.
Why doesn't ActionLink have a deferrable listener?
Probably because there isn't such a nice place to defer to - the Submit
etc components live in a form so their l
Ignore the suggestion to also incorporate this into ActionLink - this
really only makes sense for components with deferable listeners.
Richard Lewis-Shell wrote:
I've implemented this for Submit (really just to test the idea) and it
seems to work. This is a little less radical than E
easier to start with)
Richard
Richard Lewis-Shell wrote:
This could also work for ActionLink too. I re-read the blog/thread on
improved listener methods, and those changes seem to fit in with using
immediate and deferred listeners to remember rewind state. So, let me
firm this up a bit.
Im
Imagine.html:
click me
Imagine this instead:
click me
This is how I've implemented this with my ParamLink/ParamService. I
pass a Map with named key/value pairs as the first listener parameter.
You win! Does that prevent informal parameters from being rendered as
attributes?
Richard
-
that prefer named parameters, perhaps both could be implemented?
Richard
Richard Lewis-Shell wrote:
When will a deferred listener be *constructed* (as oppsosed to invoked)?
Immediately, or also deferred? I am hoping it is immediate.
In previous Tapestry projects we have created wrappers
When will a deferred listener be *constructed* (as oppsosed to invoked)?
Immediately, or also deferred? I am hoping it is immediate.
In previous Tapestry projects we have created wrappers for the submit
components to implement this (using selected/tag), and have made use of
a deferredListener
[
http://issues.apache.org/jira/browse/TAPESTRY-166?page=comments#action_64787 ]
Richard Lewis-Shell commented on TAPESTRY-166:
--
LinkSubmit?
> Allow Submits to defer invoking their liste
Richard Lewis-Shell: +1 (binding)
Brian K. Wallace wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
+1 non-binding
Howard Lewis Ship wrote:
| Now that HiveMind 1.1 has entered beta, I believe it's time to release
a new
| alpha of Tapestry 4.0 (Picasso). This will give people a chance t
What about if the syntax was:
Then the method name is simply followed by an OGNL expression resulting
in the list of parameters, so it'd be simpler to implement (I imagine),
but perhaps not as clear as using ()s.
Richard
Erik Hatcher wrote:
On Apr 14, 2005, at 6:43 PM, Jamie wrote:
That's an in
I think this is more likely to complicate matters than simplify them.
We'll still need to replace @since, we'll still need to plan which
features go into which release, and we'll still have to consider the
implications of making a release a .1 increment over a 1.0 - IMO these
should happen up f
3.5 or 4.0 would seem appropriate to me.
So: +1
Howard Lewis Ship wrote:
The sentiment of the community seems to be that the next major release of
Tapestry (i.e., HiveMind infrastructure, Portlet support, etc.) is too
different from Tapestry 3.0 to be called "Tapestry 3.1". This release
will only
64 matches
Mail list logo
