An unfair comparison; those other projects started with a hierarchical
employee situations, developed an internal framework, then
open-sourced it. Tapestry has evolved as an open source project
entirely. I can guide it as best I can, but nobody is in a position to
"order" others to follow a proced
Hehehe,.That's easy to say ;)
On 11/29/05, Cliff Zhao <[EMAIL PROTECTED]> wrote:
>
> I have the exactly same feeling as you.
>
> Tapestry needs to learn the management aspect from other open source
> projects such as Eclipse, Spring Framework, etc.
>
>
>
> On 11/29/05, Patrick Casey <[EMAIL PR
I have the exactly same feeling as you.
Tapestry needs to learn the management aspect from other open source
projects such as Eclipse, Spring Framework, etc.
On 11/29/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
>
> >
> > You cannot be serious. C'mon, are you saying that
> > dealing with "black
Just hypothetically, what's the possibility of throwing it all away and
just include an integration layer with the old components / pages?
It may be cheaper that evolving? Is it possible?
--
Ing. Leonardo Quijano Vincenzi
DTQ Software
Howard Lewis Ship wrote:
This is the direction I'm looki
This is the direction I'm looking to evolve the framework.
This will start being easier in 4.1. I'll be able to seperate user
code from framework code since user code will no longer extend from
Tapestry base classes (a compatibility layer will remain until 4.2 or
4.3).
Right now, Tapestry code and
In this point I think is *very* important to have a design plan for
Tapestry. Probably the main cause of going from beta to beta is random
API changes because of the "this is better..."... "no! this is even
better!" ... "no, that was broken, it doesn't support X"...etc cycle.
A release plan ca
>
> You cannot be serious. C'mon, are you saying that
> dealing with "blackboxed" product bug helps your
> personal productivity?!
>
> "Common good" is a worthy purpose, but even on very
> pragmatic, personal and immediate level it is highly
> rewarding to be able to dive into somebody else's co
When I'm
> working on a commercial
> product though, I'll never go out of my way to
> expose myself to additional
> somebody else's bugs in order to fix them. I just
> can't afford that big a
> potential hit in my personal productivity, whatever
> the advantages to
> society at large.
>
>
> Didn't mention that if you found a bug and maybe even help to fix it
> or you're experience help correcting a wired behaviour, you could
> contribute something back to the project as well.
>
> Regards
> --
> Massimo
Fundamentally though, I'm not in the business of debugging Tapestry.
I understand Patrick's stand. Tapestry 4.0 is still changing its API from
beta to beta. I understand different projects have different policies on
betas and RCs. Does Tapestry have a stated policy somewhere? What's the
milestone for an API freezing? I can feel the frustration that a big chunk
of wo
On 11/29/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
[..]
> I have to debug the Beta as well, doubling my search space.
These are usual phrases, and this is an argument of usual debate.
Every project has different ways of thinking (which just reflect the
leading developers ideas), the general me
> Well, I think you should start with 4 even if it's named beta right
> now, plus that you could switch to release when it will be available
> (not so far), looking at 4.0 as the unstable and untrusted branch is a
> wrong assumption right now. We even may see RC pretty soon.
> Read the archive and
I am waiting for Spindle!
-Original Message-
From: Massimo Lusetti [mailto:[EMAIL PROTECTED]
Sent: Wed 11/23/2005 2:37 AM
To: Tapestry users
Subject: Re: A Bit of Profiling Goodness
On 11/22/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
> When it goes GA I'll pro
I have the same problems. I have a massive tapestry app and it appears at least
45% of the time is spent in OGNL (vs. 30% in database/datamapping code). I'm
using 3.03 as well because I have similar deadlines to meet and rewrote a bit
too much of 3.0 last year to support some of the features tha
On 11/22/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
> When it goes GA I'll probably run some tests on it, but I'm actually
> working on a project which is supposed to come out around new years so I
> need to stay on released code.
Well, I think you should start with 4 even if it's named
ry users
> Subject: Re: A Bit of Profiling Goodness
>
> On 11/22/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
>
> > Ack, sorry I didn't include that. Tapestry 3.0.3.
>
> I would really
On 11/22/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
> Ack, sorry I didn't include that. Tapestry 3.0.3.
I would really like to see this kind of test with 4.0
--
Massimo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Ack, sorry I didn't include that. Tapestry 3.0.3.
--- Pat
> -Original Message-
> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 21, 2005 7:51 PM
> To: Tapestry users
> Subject: Re: A Bit of Profiling Goodness
>
&
lterable wall of the java reflection API, *then* you
> byte-code enhancement approach may be the only solution. After my first
> round of sandbox testing though, I'd begun to let myself hope there might be
> a silver bullet out there. Now, I'm quite a bit less confident.
>
&g
---
> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 21, 2005 3:19 PM
> To: Tapestry users
> Subject: Re: A Bit of Profiling Goodness
>
> Wondering if you could also try OGNL using compiled expressions? That
> may be the problem. Tapestry compile
= 0; x < 10; x++) {
> Ognl.getValue("firstName",u);
> }
> Log.debug("Total ognl time = " + c);
>
> Its just plain dog slow :(.
>
> --- Pat
>
> > -Original Message
("firstName",u);
}
Log.debug("Total ognl time = " + c);
Its just plain dog slow :(.
--- Pat
> -Original Message-
> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 21, 2005 1
Still, numbers like "46%" are hard to take out of context.
Really, the question is: "How much time is spent in OGNL and is it
affecting performance/scalability?"
Not sure how to qualify this. Seems to me that smarter transaction
management, better queries, and good caching will always be better
23 matches
Mail list logo
