+1
It will be selfish for someone to preventing T5 only because of the
compatibility.
T5 is a renovation. When it out, everyone will be benefit.
For the future of tapestry, T5 should going on.
If you like tapestry, support it.
2006/7/29, Howard Lewis Ship <[EMAIL PROTECTED]>:
The current st
I would also suggest moving to a proven programming language like C!
Let's move forward!
Francis Amanfo wrote:
I am +1 on dumping HiveMind into the trash bin and NOT reinvent the wheel
but use the popular, innovative and proven Spring IoC framework.
I'm also +1 on giving Tapestry 5 a whole new
Bingo.
The issue isn't that having a Tap5 is important, for it is. There will
always be a need to add new features and support new technologies as a
framework expands. The issue I have is that every Tap release doesn't just
add new abilities, it completely scraps the existing code. There are
n
My bet is that Howard doesn't really know at the moment what would be
entailed in migration from 4 -> 5 and ensuring backward compatibility (not
the same thing).
I should think that he threw out this comment because it is easier for him
to think like this under the pressure of these new ideas, wit
Please do your homework before posting.
On 7/29/06, Francis Amanfo <[EMAIL PROTECTED]> wrote:
I am +1 on dumping HiveMind into the trash bin and NOT reinvent the wheel
but use the popular, innovative and proven Spring IoC framework.
I'm also +1 on giving Tapestry 5 a whole new name like "Wicked
I am +1 on dumping HiveMind into the trash bin and NOT reinvent the wheel
but use the popular, innovative and proven Spring IoC framework.
I'm also +1 on giving Tapestry 5 a whole new name like "Wicked".
F
On 7/27/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
There's been a lot of buzz on m
The current state of the T4 code is untenable w.r.t. to adding new
features without breaking backwards compatibility. Each upgrade of
Tapestry (2 to 3 to 4) has had major upgrade problems because of a
number of factors, mostly the design of the APIs and the need to
extend from base classes (as th
Howard, if it really will be as difficult to move from Tap4 to Tap5 as you
suggest, and if this new code base is indeed mostly new, perhaps it might be
prudent to release what you are now calling Tapestry 5 as a new project
instead; one that is "inspired" by the Tapestry concepts and intentions.
T
Having made the switch from 3.0 to 4.0 during the
development of Trails, it took some time but was
definitely worth it. I think 4.0 is a tremendous
improvement over 3 for sure.
However, if 5 is basically a completely new web
framework with no easy upgrade path it would be a
tough pill to swallo
Hi,
I personally don't have a problem with this, at the very least because
it is high-time for the many of the changes in T5. Nevertheless, the
majority of people will expect some kind of backward compatibility
between T4 and T5 and that expectation would be natural. Perhaps if T5
is renamed
On 7/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
We also ~never~ discussed or thought about backwards compatibility while
designing/developing a new major product version. This wasn't a clunky
little windows app we were developing either. It was a rather large fault
tolerant medical records
Howard,
"Very difficult" sounds very bad for the next major tapestry release...
Our upgrade of Tapestry 3 to Tapestry 4 took several months of working on
two branches at the same time.
We are not ready to go through that again. No matter how much unit testing
we put, there was an insane amount of
Yes really...That is pretty horribly inappropriate.
Reading the spindle blog doesn't even give me the impression Geoff has run
off to make babies with GWT either. In fact, it looks like he just released
a T4 compatible spindle plugin.
Please keep your personal attacks for some other forum, like
That's a lot of pent up anger you have there, Francis. Perhaps you need to
take a break from development if a Java web application framework can get
you that worked up. And the personal attacks are totally uncalled for.
On 7/28/06, Francis Amanfo <[EMAIL PROTECTED]> wrote:
... And that's why Ge
I think that all of this - while valid - is really just a big
misunderstanding about what phase of development Howard is at with tapestry
5.
I'll start off my email with saying I personally promise - when the time
comes for it - to create a tapestry 4 "extension" to tapestry 5 that will
allow som
... And that's why Geoff Longman dropped off the boat to pursue something
more innovative (GWT) having a solid backing by a reputable company. Not
with by a sole Saddam-like dictator like Howard. He pretends he's democratic
by throwing his ideas under the umbrella "Discuss" but meanwhile he's made
Howard, I know you're very innovative and all, but doesn't this really sound
somewhat crazy to you? If you really want Tapestry to gain acceptance, then
backward compatibility is a big issue. I jumped into the Tapestry world
with the 4.0 release and I'm really enjoying it, but if switching to 5.x
[
http://issues.apache.org/jira/browse/TAPESTRY-1026?page=comments#action_12424137
]
Matthew B. Payne commented on TAPESTRY-1026:
after above if you just search/add the following lines, it may do the trick
templateResource = get
[
http://issues.apache.org/jira/browse/TAPESTRY-1026?page=comments#action_12424135
]
Matthew B. Payne commented on TAPESTRY-1026:
Don't have a patch, but start looking in code around line 189 in
PageSpecificationResolverImpl
e.g.
PageSpecificationResolverImpl doesn't search "implict" page
specifications/templates in all the right places.
-
Key: TAPESTRY-1026
URL: http://issues.apach
I'm preparing the initial 4.1 release now. Wish me luck! :)
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
[ http://issues.apache.org/jira/browse/TAPESTRY-1024?page=all ]
Jesse Kuhnert reassigned TAPESTRY-1024:
---
Assignee: Jesse Kuhnert
> Client validation bug
> -
>
> Key: TAPESTRY-1024
> URL: http://is
[
http://issues.apache.org/jira/browse/TAPESTRY-1024?page=comments#action_12424127
]
Jesse Kuhnert commented on TAPESTRY-1024:
-
I'm not able to reproduce this bug. Using various forms of with/without
required validators my form still va
Which means: "almost impossible" :)
Howard Lewis Ship wrote:
Right now its impossible because there's nothing to convert to :-)
It will be *VERY* difficult. This isn't a slap of new paint. Basic
paradigms are shifting around in a major way. It would be comparable,
or perhaps even larger than,
Right now its impossible because there's nothing to convert to :-)
It will be *VERY* difficult. This isn't a slap of new paint. Basic
paradigms are shifting around in a major way. It would be comparable,
or perhaps even larger than, converting between JSF and Tapestry 4.
Possibly on the order of
On 7/28/06, James Carman <[EMAIL PROTECTED]> wrote:
The memory leak issue is well-known and somewhat well-documented:
http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak
Yes and this is more an underlying class loader issue rather than specific
to commons logging. I agree with
Add support for eager loading of services
-
Key: TAPESTRY-1025
URL: http://issues.apache.org/jira/browse/TAPESTRY-1025
Project: Tapestry
Issue Type: Improvement
Components: IoC Container
Yeah, that was mentioned in the original email.
_
From: Paul Ferraro [mailto:[EMAIL PROTECTED]
Sent: Friday, July 28, 2006 9:45 AM
To: Tapestry development
Subject: Re: T5: getting away from commons-logging
Has anyone considered SLF4J?
http://slf4j.org
Paul
On Fri, 2006-07-28 at
Has anyone considered SLF4J?
http://slf4j.org
Paul
On Fri, 2006-07-28 at 10:21 +0200, Massimo Lusetti wrote:
On 7/28/06, Henri Dupre <[EMAIL PROTECTED]> wrote:
> On 7/27/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
> >
> > A pretty common complaint is that commons-logging is a problem.
Maybe the option is to use a WebRequestServicerFilter or something to call:
LogFactory.release(Thread.currentThread().getContextClassLoader());
after the request is finished?
-Original Message-
From: Massimo Lusetti [mailto:[EMAIL PROTECTED]
Sent: Friday, July 28, 2006 4:22 AM
To: Tapes
The memory leak issue is well-known and somewhat well-documented:
http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak
-Original Message-
From: Massimo Lusetti [mailto:[EMAIL PROTECTED]
Sent: Friday, July 28, 2006 4:22 AM
To: Tapestry development
Subject: Re: T5: getting a
On 7/28/06, Henri Dupre <[EMAIL PROTECTED]> wrote:
On 7/27/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
>
> A pretty common complaint is that commons-logging is a problem. It
> does some wierd and awkward class loading things that ultimately
> result in memory leaks.
I think they solved th
32 matches
Mail list logo
