You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2006/04/26 06:39:48 UTC
Tapestry 5 progress
I'm having a lot of fun with the tapestry5 code.
Back in January 2000, I spent almost two weeks getting Tapestry from
an idea to a lame "Hello World". I had to do lots of work and learn
many things, including the SAX API, designing and implementing the
component specification hierarchy, designing and implementing the
component structure, all the reflective instantiation, the initial
primitive template parser, and so forth.
I think that time was well spent, it "injected energy" into Tapestry
that served it well for several years, giving it a powerful core that
was quite amenable to change and improvement.
I'm putting much more effort into the new code base, along with six
years of accumulated experience. It feels like I'm winding it up like
a spring (no pun intended). It's exhilarating.
Right now, what I'm building looks more like an AOP system than a web
framework ... that'll come later. I need to catch up on Jesse's work
on the JSOnRenderer since those ideas should be folded in and
improved.
On 4/25/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> I'm green with envy! I knew starting more of that autocompleter support
> would only make me depressed because I'd have to leave it before I was
> finished for this traveling work I'm in the middle of this week.
>
> I'll see if I can catch up in pulling my coding weight when I get back. Nice
> to see so much work going on. You must be having a lot of fun being able to
> design around these concepts :(
>
> On 4/24/06, hlship@apache.org <hl...@apache.org> wrote:
> >
> > Author: hlship
> > Date: Mon Apr 24 17:52:01 2006
> > New Revision: 396751
> >
> > URL: http://svn.apache.org/viewcvs?rev=396751&view=rev
> > Log:
> > Make ComponentLifecycle extend from ResourceAware.
> > Move core initialization logic (i.e., components implement
> > ComponentLifecycle) into InternalComponentTransformationImpl.
> > Remove the readMeta() and writeMeta() methods from ComponentTransformation
> > Add getResourcesFieldName() method to ComponentTransformation
> > Modify the ComponentTransformation to be frozen after invoking finish()
> >
> > Removed:
> >
> > tapestry/tapestry5/tapestry-core/trunk/src/main/java/org/apache/tapestry/internal/transform/worker/ImplementResourceAwareWorker.java
> >
> > tapestry/tapestry5/tapestry-core/trunk/src/test/java/org/apache/tapestry/internal/transform/worker/ImplementResourceAwareWorkerTest.java
> > Modified:
> > tapestry/tapestry5/tapestry-core/trunk/src/main/java/org
>
>
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind.
>
>
--
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: Tapestry 5 progress
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I was going to say something about this but figured you'd chime in on
it. :-)
Geoff Longman wrote:
> Well, I would be remiss if I didn't add the obligatory tool support whine.
>
> Any progress on my ideas for project layout or is the work so far
> restircted to runtime stuff so far?
>
> Geoff
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFET3I1aCoPKRow/gARAm/cAKCL1nzQ8vlD5y3Of7UypVHZeMgHrQCeMnCR
FR/7dpX7lQ6G6eom2GjYwGo=
=RSsp
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by Geoff Longman <gl...@gmail.com>.
Well, I would be remiss if I didn't add the obligatory tool support whine.
Any progress on my ideas for project layout or is the work so far
restircted to runtime stuff so far?
Geoff
On 4/26/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> I'm having a lot of fun with the tapestry5 code.
>
> Back in January 2000, I spent almost two weeks getting Tapestry from
> an idea to a lame "Hello World". I had to do lots of work and learn
> many things, including the SAX API, designing and implementing the
> component specification hierarchy, designing and implementing the
> component structure, all the reflective instantiation, the initial
> primitive template parser, and so forth.
>
> I think that time was well spent, it "injected energy" into Tapestry
> that served it well for several years, giving it a powerful core that
> was quite amenable to change and improvement.
>
> I'm putting much more effort into the new code base, along with six
> years of accumulated experience. It feels like I'm winding it up like
> a spring (no pun intended). It's exhilarating.
>
> Right now, what I'm building looks more like an AOP system than a web
> framework ... that'll come later. I need to catch up on Jesse's work
> on the JSOnRenderer since those ideas should be folded in and
> improved.
>
>
> On 4/25/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> > I'm green with envy! I knew starting more of that autocompleter support
> > would only make me depressed because I'd have to leave it before I was
> > finished for this traveling work I'm in the middle of this week.
> >
> > I'll see if I can catch up in pulling my coding weight when I get back. Nice
> > to see so much work going on. You must be having a lot of fun being able to
> > design around these concepts :(
> >
> > On 4/24/06, hlship@apache.org <hl...@apache.org> wrote:
> > >
> > > Author: hlship
> > > Date: Mon Apr 24 17:52:01 2006
> > > New Revision: 396751
> > >
> > > URL: http://svn.apache.org/viewcvs?rev=396751&view=rev
> > > Log:
> > > Make ComponentLifecycle extend from ResourceAware.
> > > Move core initialization logic (i.e., components implement
> > > ComponentLifecycle) into InternalComponentTransformationImpl.
> > > Remove the readMeta() and writeMeta() methods from ComponentTransformation
> > > Add getResourcesFieldName() method to ComponentTransformation
> > > Modify the ComponentTransformation to be frozen after invoking finish()
> > >
> > > Removed:
> > >
> > > tapestry/tapestry5/tapestry-core/trunk/src/main/java/org/apache/tapestry/internal/transform/worker/ImplementResourceAwareWorker.java
> > >
> > > tapestry/tapestry5/tapestry-core/trunk/src/test/java/org/apache/tapestry/internal/transform/worker/ImplementResourceAwareWorkerTest.java
> > > Modified:
> > > tapestry/tapestry5/tapestry-core/trunk/src/main/java/org
> >
> >
> >
> >
> > --
> > Jesse Kuhnert
> > Tacos/Tapestry, team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind.
> >
> >
>
>
> --
> 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
>
>
--
The Spindle guy. http://spindle.sf.net
Blog: http://jroller.com/page/glongman
Other interests: http://www.squidoo.com/spaceelevator/
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by adasal <ad...@gmail.com>.
re: thread Make validation errors appear before a form is submitted and
Tapestry 5
Just a couple of thoughts.
I have had a further conversation with gaz (c.f. the other thread. I work
with him, so that type of thing is possible -:)).
The problem that has been found is to do with the rendering of errors in the
validation (sub) framework - field tracking. Field tracking requires a
submit for it to be initialised.
My thoughts are not about the problem gaz has, but about the Tapestry
framework.
The error mechanisms would have to be further decoupled. No one would have
anticipated that this might be an issue to begin with, but maybe by finding
these things it is how frameworks evolve?
Would it be possible to treat the validation mechanisms as a completely
modular service?
Well, I imagine that by Howard developing using an AOP framework all of this
sort of thing is anticipated in one fell swoop? I already thought AOP was
good using hivemind 1.1, but can see that it can be pushed.
I just want to emphasise the usefulness of this re. error checking.
Actually, error checking and rules integration is becoming a fundamental
part of a more sophisticated app. I know it sounds like hot air, and I don't
have a working example, but it seems to me that more formal languages for
rules are going to be playing a part here as will the use of tags in some
form (maybe I will have Jesse on my side here?)
These more formal languages might control workflow, and, going back to the
original issue, workflow often has to do with error catching and exception
processing. So every little bit that makes it more feasible to implement
this in Tapestry moves Tapestry closer to this territory. IMO Tapestry is
highly suitable for integration with other open source solutions in this
area, but however it is done I anticipate it will be!
Adam
On 26/04/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> The basic AOP infrastructure is coming along. I expect the rest to
> ramp up pretty quickly once I get that in place, but we're still
> talking months. Maybe a useable beta by year's end.
>
> I think I predicted a big performance boost for Tapestry 4 apps vs.
> equivalent Tapestry 3 apps. I believe the difference between 4 and 5
> will be greater. In fact, I expect OGNL support to be an add on, and
> the built-in code will be an improved version of tapestry-prop (from
> Tapestry @ JavaForge). I want Tapestry to be extremely high
> performance, as one of its differentiators from JSF and Rails.
>
>
> On 4/25/06, Brian K. Wallace < brian@transmorphix.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > First off - this is great news (IMO). It's great to see a new look as
> > it's being checked in.
> >
> > The following is nothing short of my own idle curiosity: when do you /
> > would you envision 5 rolling out? [no jumping down the new guy's throat
> > - - I'm just curious. I know there's a lot left before anything thrown
> out
> > would be anything more than conjecture/hope] I'm really looking forward
> > to seeing the two sides (Howard's / Jesse's) meeting and pushing
> > Tapestry that much farther.
> >
> > Howard Lewis Ship wrote:
> > > I'm having a lot of fun with the tapestry5 code.
> > >
> > > Back in January 2000, I spent almost two weeks getting Tapestry from
> > > an idea to a lame "Hello World". I had to do lots of work and learn
> > > many things, including the SAX API, designing and implementing the
> > > component specification hierarchy, designing and implementing the
> > > component structure, all the reflective instantiation, the initial
> > > primitive template parser, and so forth.
> > >
> > > I think that time was well spent, it "injected energy" into Tapestry
> > > that served it well for several years, giving it a powerful core that
> > > was quite amenable to change and improvement.
> > >
> > > I'm putting much more effort into the new code base, along with six
> > > years of accumulated experience. It feels like I'm winding it up like
>
> > > a spring (no pun intended). It's exhilarating.
> > >
> > > Right now, what I'm building looks more like an AOP system than a web
> > > framework ... that'll come later. I need to catch up on Jesse's work
> > > on the JSOnRenderer since those ideas should be folded in and
> > > improved.
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.5 (MingW32)
> >
> > iD8DBQFETwNAaCoPKRow/gARAlfxAKCOquc4t/i/2XbEqBEd+NMDNU8eBgCg2gkd
> > GC8fEpi5KxHSfi8xSvXQHsA=
> > =9v6P
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> 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: Tapestry 5 progress
Posted by Fernando Padilla <fe...@alum.mit.edu>.
Alright, I apologize again, I guess the concept is a little convoluted,
but you'll have to have a little open mind, I think it works...
You will have to add another "render cycle". Currently there are two
render cycles, Rewind and Render. Essentially a render cycle walks
through the component tree allowing each component to do what needs to
be done during that cycle. Currently there is:
1) rewind
- have component tree absorb form parameters
2) render
- render html from component tree
What we'll have to do is to add a cacheInfo cycle:
1) rewind
- have component tree absorb form parameters
2) cacheInfo
- get cacheInfo from component tree
3) render (unless cacheInfo says we don't need to)
- render html from component tree
During the cacheInfo cycle we would simply interrogate each component to
give us its cacheInfo. A Component could then:
- not set any cacheInfo
- stating that it defers to child components
- set equivalent to do-not-cache ( expires=0, lastmod=0, etc )
- this means that it's not cacheable
- set appropriate lastmod/expires info
- this of course depends on application logic....
- something to remember is that at the lowest level is the .html file
- so that would use the lastmod of the file itself
The framework would then just have to collect and aggregate this
information in some predictable way ( greatest lastmod, smallest expires
).. and voila.. we have lastmod/expires information for any part of the
component tree.. Then the framework could return a NOT_MODIFIED if the
lastmod matches, etc.... We could then put a HTTP-Cache in front of our
servlet somehow.
Of course the benefits are:
- faster response
- higher throughput
- less CPU ( web, db )
- less bandwidth ( to a slow client could mean alot! )
but:
- lastmod must be less expensive/faster than a full render.
- pages must not change too much..
And if you don't want the functionality, because it doesn't have the
desired ROI, then just turn off cacheInfo cycle.
andyhot@di.uoa.gr wrote:
> I've also read Fernando's previous email and it looks like a very
> interesting idea.
> However, i see a few problems:
> - you can't tell which sub-components will render until you
> actually render their containing component. So, if this must happen,
> what exactly are the gains? Are you interested in network traffic,
> server load, or both?
> - How exactly will people implement lastmodified/expires at the
> component level? It seems it will always depend on the context on
> which each component is used and so it cannot be implemented at
> that level.
>
> The way i see it, this would have to be addressed at the page level,
> meaning that the user will have to implement all the
> lastmodified-expires logic on his own. But it still is a step forward.
>
> From Fernando Padilla <fe...@alum.mit.edu>:
>
>
>>true.
>>
>>that is why the framework can't be smart enough to do this by it self.
>>
>>I apologize, in this email I was refering to an earlier email that I
>>sent out a while ago..
>>
>>In that email I was asking for framework support for
>>lastmodified/expires throughout the component tree. So that people
>>could implement lastmodified/expires at the component level, and the
>>framework would simply aggregate this information and could tell you the
>>lastmodified/expires for a whole page, or simply a portion of the
>>component tree.
>>
>>That way if I implement a component of some complexity I could scope the
>>lastmodified/expires logic where it should live ( on that component ),
>>and have it instantly integrated wherever page or super component it
>>might be used.
>>
>>So with "proper" support for lastmodified/expires from the framework,
>>every page from tapestry could work appropriately with any standard HTTP
>>cache mechanism. So with some work you can increase the scalability of
>>your tapestry application, within the component-based framework, not
>>through any hacks.
>>
>>Currently I have to implement the lastmodified/expires logic as a filter
>>ontop of Tapestry that looks for particular urls...
>>
>>fernando
>>
>>By the way, we put squid in front of our servers and we have a cache hit
>>of about 80%. And with some of the client-side-include work that I'll
>>be integrating, we will get even more!
>>
>>
>>Howard Lewis Ship wrote:
>>
>>>What is "properly"? That is, when a page is constructed by pulling
>>>data out of some large collection of database entities and stateful
>>>server-side properties, any of which may have changed between
>>>timepoint A and timepoint B, how do you effectively and efficiently
>>>determine that something is "out of date" at timepoint B? It is not a
>>>trivial problem to solve, it may be THE problem in server side web
>>>development.
>>>
>>>On 4/26/06, Fernando Padilla <fe...@alum.mit.edu> wrote:
>>>
>>>
>>>>I can't resist commenting on your "cache" feature :) :)
>>>>
>>>>just support lastModified and expires properly! :) then you can simply
>>>>put Squid in front of your server, or we can develop a basic
>>>>SquidFilter. :) :)
>>>>
>>>>
>>>>Brian K. Wallace wrote:
>>>>
>>>>
>>>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>>>Hash: SHA1
>>>>>
>>>>>Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
>>>>>I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
>>>>>speed before 5 hits. (feed the masses and all that :-))
>>>>>
>>>>>In speaking of performance... (I'm off in dream land here, I know... but
>>>>>I like it there sometimes)
>>>>>
>>>>>Many moons ago, there was talk of a 'tool' /'utility' that would
>>>>>basically spider a Tapestry app and get all the generated HTML resulting
>>>>>in basically a statically generated site. This helps tremendously when
>>>>>you're running behind a web server that's tuned to serve static content
>>>>>- - it's what they do and they do it pretty well with no overhead past
>>>>>itself (meaning no java, no db, etc). I'd like to see if we can't add
>>>>>some sort of 'cache' attribute to the HTML (somewhere) that would allow
>>>>>Tapestry to perform this type of "wait, it says to cache it - i've
>>>>>already generated it, I'll just grab that and use it" processing. This
>>>>>would also allow Tapestry to build on first access but write out the
>>>>>generated HTML so the next time a request comes in for it, the web
>>>>>server would find it first (outside the mapping for Tapestry). Granted
>>>>>this would only work for pages that were "cache=true" and had no dynamic
>>>>>components inside it, but for a lot of sites that's enough (especially
>>>>>outside a 'user' area). If there's a static form, submitting it would
>>>>>pass back to Tapestry for processing.
>>>>>
>>>>>I'd see this as only improving performance if you run Tapestry behind
>>>>>something like Apache. Granted, you'd get a lot of "that's not fair -
>>>>>you're not comparing our framework to yours if you don't hit your
>>>>>framework more than once when we have to hit ours every time"
>>>>>comments... but hey ;-)
>>>>>
>>>>>My .02
>>>>>Brian
>>>>>
>>>>>Howard Lewis Ship wrote:
>>>>>
>>>>>
>>>>>
>>>>>>The basic AOP infrastructure is coming along. I expect the rest to
>>>>>>ramp up pretty quickly once I get that in place, but we're still
>>>>>>talking months. Maybe a useable beta by year's end.
>>>>>>
>>>>>>I think I predicted a big performance boost for Tapestry 4 apps vs.
>>>>>>equivalent Tapestry 3 apps. I believe the difference between 4 and 5
>>>>>>will be greater. In fact, I expect OGNL support to be an add on, and
>>>>>>the built-in code will be an improved version of tapestry-prop (from
>>>>>>Tapestry @ JavaForge). I want Tapestry to be extremely high
>>>>>>performance, as one of its differentiators from JSF and Rails.
>>>>>>
>>>>>
>>>>>
>>>>>-----BEGIN PGP SIGNATURE-----
>>>>>Version: GnuPG v1.2.5 (MingW32)
>>>>>
>>>>>iD8DBQFETw8naCoPKRow/gARAvd+AKCDU/DGNTKXPfhaJyb+5oNlMT0S1wCcC4ZE
>>>>>stsYXpMZrbap+Q7Jxn+Lh0k=
>>>>>=xbzo
>>>>>-----END PGP SIGNATURE-----
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>>--
>>>Howard M. Lewis Ship
>>>Independent J2EE / Open-Source Java Consultant
>>>Creator and PMC Chair, Apache 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
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by an...@di.uoa.gr.
I've also read Fernando's previous email and it looks like a very
interesting idea.
However, i see a few problems:
- you can't tell which sub-components will render until you
actually render their containing component. So, if this must happen,
what exactly are the gains? Are you interested in network traffic,
server load, or both?
- How exactly will people implement lastmodified/expires at the
component level? It seems it will always depend on the context on
which each component is used and so it cannot be implemented at
that level.
The way i see it, this would have to be addressed at the page level,
meaning that the user will have to implement all the
lastmodified-expires logic on his own. But it still is a step forward.
>From Fernando Padilla <fe...@alum.mit.edu>:
> true.
>
> that is why the framework can't be smart enough to do this by it self.
>
> I apologize, in this email I was refering to an earlier email that I
> sent out a while ago..
>
> In that email I was asking for framework support for
> lastmodified/expires throughout the component tree. So that people
> could implement lastmodified/expires at the component level, and the
> framework would simply aggregate this information and could tell you the
> lastmodified/expires for a whole page, or simply a portion of the
> component tree.
>
> That way if I implement a component of some complexity I could scope the
> lastmodified/expires logic where it should live ( on that component ),
> and have it instantly integrated wherever page or super component it
> might be used.
>
> So with "proper" support for lastmodified/expires from the framework,
> every page from tapestry could work appropriately with any standard HTTP
> cache mechanism. So with some work you can increase the scalability of
> your tapestry application, within the component-based framework, not
> through any hacks.
>
> Currently I have to implement the lastmodified/expires logic as a filter
> ontop of Tapestry that looks for particular urls...
>
> fernando
>
> By the way, we put squid in front of our servers and we have a cache hit
> of about 80%. And with some of the client-side-include work that I'll
> be integrating, we will get even more!
>
>
> Howard Lewis Ship wrote:
> > What is "properly"? That is, when a page is constructed by pulling
> > data out of some large collection of database entities and stateful
> > server-side properties, any of which may have changed between
> > timepoint A and timepoint B, how do you effectively and efficiently
> > determine that something is "out of date" at timepoint B? It is not a
> > trivial problem to solve, it may be THE problem in server side web
> > development.
> >
> > On 4/26/06, Fernando Padilla <fe...@alum.mit.edu> wrote:
> >
> >>I can't resist commenting on your "cache" feature :) :)
> >>
> >>just support lastModified and expires properly! :) then you can simply
> >>put Squid in front of your server, or we can develop a basic
> >>SquidFilter. :) :)
> >>
> >>
> >>Brian K. Wallace wrote:
> >>
> >>>-----BEGIN PGP SIGNED MESSAGE-----
> >>>Hash: SHA1
> >>>
> >>>Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
> >>>I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
> >>>speed before 5 hits. (feed the masses and all that :-))
> >>>
> >>>In speaking of performance... (I'm off in dream land here, I know... but
> >>>I like it there sometimes)
> >>>
> >>>Many moons ago, there was talk of a 'tool' /'utility' that would
> >>>basically spider a Tapestry app and get all the generated HTML resulting
> >>>in basically a statically generated site. This helps tremendously when
> >>>you're running behind a web server that's tuned to serve static content
> >>>- - it's what they do and they do it pretty well with no overhead past
> >>>itself (meaning no java, no db, etc). I'd like to see if we can't add
> >>>some sort of 'cache' attribute to the HTML (somewhere) that would allow
> >>>Tapestry to perform this type of "wait, it says to cache it - i've
> >>>already generated it, I'll just grab that and use it" processing. This
> >>>would also allow Tapestry to build on first access but write out the
> >>>generated HTML so the next time a request comes in for it, the web
> >>>server would find it first (outside the mapping for Tapestry). Granted
> >>>this would only work for pages that were "cache=true" and had no dynamic
> >>>components inside it, but for a lot of sites that's enough (especially
> >>>outside a 'user' area). If there's a static form, submitting it would
> >>>pass back to Tapestry for processing.
> >>>
> >>>I'd see this as only improving performance if you run Tapestry behind
> >>>something like Apache. Granted, you'd get a lot of "that's not fair -
> >>>you're not comparing our framework to yours if you don't hit your
> >>>framework more than once when we have to hit ours every time"
> >>>comments... but hey ;-)
> >>>
> >>>My .02
> >>>Brian
> >>>
> >>>Howard Lewis Ship wrote:
> >>>
> >>>
> >>>>The basic AOP infrastructure is coming along. I expect the rest to
> >>>>ramp up pretty quickly once I get that in place, but we're still
> >>>>talking months. Maybe a useable beta by year's end.
> >>>>
> >>>>I think I predicted a big performance boost for Tapestry 4 apps vs.
> >>>>equivalent Tapestry 3 apps. I believe the difference between 4 and 5
> >>>>will be greater. In fact, I expect OGNL support to be an add on, and
> >>>>the built-in code will be an improved version of tapestry-prop (from
> >>>>Tapestry @ JavaForge). I want Tapestry to be extremely high
> >>>>performance, as one of its differentiators from JSF and Rails.
> >>>>
> >>>
> >>>
> >>>-----BEGIN PGP SIGNATURE-----
> >>>Version: GnuPG v1.2.5 (MingW32)
> >>>
> >>>iD8DBQFETw8naCoPKRow/gARAvd+AKCDU/DGNTKXPfhaJyb+5oNlMT0S1wCcC4ZE
> >>>stsYXpMZrbap+Q7Jxn+Lh0k=
> >>>=xbzo
> >>>-----END PGP SIGNATURE-----
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Howard M. Lewis Ship
> > Independent J2EE / Open-Source Java Consultant
> > Creator and PMC Chair, Apache 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by Fernando Padilla <fe...@alum.mit.edu>.
true.
that is why the framework can't be smart enough to do this by it self.
I apologize, in this email I was refering to an earlier email that I
sent out a while ago..
In that email I was asking for framework support for
lastmodified/expires throughout the component tree. So that people
could implement lastmodified/expires at the component level, and the
framework would simply aggregate this information and could tell you the
lastmodified/expires for a whole page, or simply a portion of the
component tree.
That way if I implement a component of some complexity I could scope the
lastmodified/expires logic where it should live ( on that component ),
and have it instantly integrated wherever page or super component it
might be used.
So with "proper" support for lastmodified/expires from the framework,
every page from tapestry could work appropriately with any standard HTTP
cache mechanism. So with some work you can increase the scalability of
your tapestry application, within the component-based framework, not
through any hacks.
Currently I have to implement the lastmodified/expires logic as a filter
ontop of Tapestry that looks for particular urls...
fernando
By the way, we put squid in front of our servers and we have a cache hit
of about 80%. And with some of the client-side-include work that I'll
be integrating, we will get even more!
Howard Lewis Ship wrote:
> What is "properly"? That is, when a page is constructed by pulling
> data out of some large collection of database entities and stateful
> server-side properties, any of which may have changed between
> timepoint A and timepoint B, how do you effectively and efficiently
> determine that something is "out of date" at timepoint B? It is not a
> trivial problem to solve, it may be THE problem in server side web
> development.
>
> On 4/26/06, Fernando Padilla <fe...@alum.mit.edu> wrote:
>
>>I can't resist commenting on your "cache" feature :) :)
>>
>>just support lastModified and expires properly! :) then you can simply
>>put Squid in front of your server, or we can develop a basic
>>SquidFilter. :) :)
>>
>>
>>Brian K. Wallace wrote:
>>
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
>>>I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
>>>speed before 5 hits. (feed the masses and all that :-))
>>>
>>>In speaking of performance... (I'm off in dream land here, I know... but
>>>I like it there sometimes)
>>>
>>>Many moons ago, there was talk of a 'tool' /'utility' that would
>>>basically spider a Tapestry app and get all the generated HTML resulting
>>>in basically a statically generated site. This helps tremendously when
>>>you're running behind a web server that's tuned to serve static content
>>>- - it's what they do and they do it pretty well with no overhead past
>>>itself (meaning no java, no db, etc). I'd like to see if we can't add
>>>some sort of 'cache' attribute to the HTML (somewhere) that would allow
>>>Tapestry to perform this type of "wait, it says to cache it - i've
>>>already generated it, I'll just grab that and use it" processing. This
>>>would also allow Tapestry to build on first access but write out the
>>>generated HTML so the next time a request comes in for it, the web
>>>server would find it first (outside the mapping for Tapestry). Granted
>>>this would only work for pages that were "cache=true" and had no dynamic
>>>components inside it, but for a lot of sites that's enough (especially
>>>outside a 'user' area). If there's a static form, submitting it would
>>>pass back to Tapestry for processing.
>>>
>>>I'd see this as only improving performance if you run Tapestry behind
>>>something like Apache. Granted, you'd get a lot of "that's not fair -
>>>you're not comparing our framework to yours if you don't hit your
>>>framework more than once when we have to hit ours every time"
>>>comments... but hey ;-)
>>>
>>>My .02
>>>Brian
>>>
>>>Howard Lewis Ship wrote:
>>>
>>>
>>>>The basic AOP infrastructure is coming along. I expect the rest to
>>>>ramp up pretty quickly once I get that in place, but we're still
>>>>talking months. Maybe a useable beta by year's end.
>>>>
>>>>I think I predicted a big performance boost for Tapestry 4 apps vs.
>>>>equivalent Tapestry 3 apps. I believe the difference between 4 and 5
>>>>will be greater. In fact, I expect OGNL support to be an add on, and
>>>>the built-in code will be an improved version of tapestry-prop (from
>>>>Tapestry @ JavaForge). I want Tapestry to be extremely high
>>>>performance, as one of its differentiators from JSF and Rails.
>>>>
>>>
>>>
>>>-----BEGIN PGP SIGNATURE-----
>>>Version: GnuPG v1.2.5 (MingW32)
>>>
>>>iD8DBQFETw8naCoPKRow/gARAvd+AKCDU/DGNTKXPfhaJyb+5oNlMT0S1wCcC4ZE
>>>stsYXpMZrbap+Q7Jxn+Lh0k=
>>>=xbzo
>>>-----END PGP SIGNATURE-----
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator and PMC Chair, Apache 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by Howard Lewis Ship <hl...@gmail.com>.
What is "properly"? That is, when a page is constructed by pulling
data out of some large collection of database entities and stateful
server-side properties, any of which may have changed between
timepoint A and timepoint B, how do you effectively and efficiently
determine that something is "out of date" at timepoint B? It is not a
trivial problem to solve, it may be THE problem in server side web
development.
On 4/26/06, Fernando Padilla <fe...@alum.mit.edu> wrote:
> I can't resist commenting on your "cache" feature :) :)
>
> just support lastModified and expires properly! :) then you can simply
> put Squid in front of your server, or we can develop a basic
> SquidFilter. :) :)
>
>
> Brian K. Wallace wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
> > I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
> > speed before 5 hits. (feed the masses and all that :-))
> >
> > In speaking of performance... (I'm off in dream land here, I know... but
> > I like it there sometimes)
> >
> > Many moons ago, there was talk of a 'tool' /'utility' that would
> > basically spider a Tapestry app and get all the generated HTML resulting
> > in basically a statically generated site. This helps tremendously when
> > you're running behind a web server that's tuned to serve static content
> > - - it's what they do and they do it pretty well with no overhead past
> > itself (meaning no java, no db, etc). I'd like to see if we can't add
> > some sort of 'cache' attribute to the HTML (somewhere) that would allow
> > Tapestry to perform this type of "wait, it says to cache it - i've
> > already generated it, I'll just grab that and use it" processing. This
> > would also allow Tapestry to build on first access but write out the
> > generated HTML so the next time a request comes in for it, the web
> > server would find it first (outside the mapping for Tapestry). Granted
> > this would only work for pages that were "cache=true" and had no dynamic
> > components inside it, but for a lot of sites that's enough (especially
> > outside a 'user' area). If there's a static form, submitting it would
> > pass back to Tapestry for processing.
> >
> > I'd see this as only improving performance if you run Tapestry behind
> > something like Apache. Granted, you'd get a lot of "that's not fair -
> > you're not comparing our framework to yours if you don't hit your
> > framework more than once when we have to hit ours every time"
> > comments... but hey ;-)
> >
> > My .02
> > Brian
> >
> > Howard Lewis Ship wrote:
> >
> >>The basic AOP infrastructure is coming along. I expect the rest to
> >>ramp up pretty quickly once I get that in place, but we're still
> >>talking months. Maybe a useable beta by year's end.
> >>
> >>I think I predicted a big performance boost for Tapestry 4 apps vs.
> >>equivalent Tapestry 3 apps. I believe the difference between 4 and 5
> >>will be greater. In fact, I expect OGNL support to be an add on, and
> >>the built-in code will be an improved version of tapestry-prop (from
> >>Tapestry @ JavaForge). I want Tapestry to be extremely high
> >>performance, as one of its differentiators from JSF and Rails.
> >>
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.5 (MingW32)
> >
> > iD8DBQFETw8naCoPKRow/gARAvd+AKCDU/DGNTKXPfhaJyb+5oNlMT0S1wCcC4ZE
> > stsYXpMZrbap+Q7Jxn+Lh0k=
> > =xbzo
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache 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: Tapestry 5 progress
Posted by Fernando Padilla <fe...@alum.mit.edu>.
I can't resist commenting on your "cache" feature :) :)
just support lastModified and expires properly! :) then you can simply
put Squid in front of your server, or we can develop a basic
SquidFilter. :) :)
Brian K. Wallace wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
> I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
> speed before 5 hits. (feed the masses and all that :-))
>
> In speaking of performance... (I'm off in dream land here, I know... but
> I like it there sometimes)
>
> Many moons ago, there was talk of a 'tool' /'utility' that would
> basically spider a Tapestry app and get all the generated HTML resulting
> in basically a statically generated site. This helps tremendously when
> you're running behind a web server that's tuned to serve static content
> - - it's what they do and they do it pretty well with no overhead past
> itself (meaning no java, no db, etc). I'd like to see if we can't add
> some sort of 'cache' attribute to the HTML (somewhere) that would allow
> Tapestry to perform this type of "wait, it says to cache it - i've
> already generated it, I'll just grab that and use it" processing. This
> would also allow Tapestry to build on first access but write out the
> generated HTML so the next time a request comes in for it, the web
> server would find it first (outside the mapping for Tapestry). Granted
> this would only work for pages that were "cache=true" and had no dynamic
> components inside it, but for a lot of sites that's enough (especially
> outside a 'user' area). If there's a static form, submitting it would
> pass back to Tapestry for processing.
>
> I'd see this as only improving performance if you run Tapestry behind
> something like Apache. Granted, you'd get a lot of "that's not fair -
> you're not comparing our framework to yours if you don't hit your
> framework more than once when we have to hit ours every time"
> comments... but hey ;-)
>
> My .02
> Brian
>
> Howard Lewis Ship wrote:
>
>>The basic AOP infrastructure is coming along. I expect the rest to
>>ramp up pretty quickly once I get that in place, but we're still
>>talking months. Maybe a useable beta by year's end.
>>
>>I think I predicted a big performance boost for Tapestry 4 apps vs.
>>equivalent Tapestry 3 apps. I believe the difference between 4 and 5
>>will be greater. In fact, I expect OGNL support to be an add on, and
>>the built-in code will be an improved version of tapestry-prop (from
>>Tapestry @ JavaForge). I want Tapestry to be extremely high
>>performance, as one of its differentiators from JSF and Rails.
>>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
>
> iD8DBQFETw8naCoPKRow/gARAvd+AKCDU/DGNTKXPfhaJyb+5oNlMT0S1wCcC4ZE
> stsYXpMZrbap+Q7Jxn+Lh0k=
> =xbzo
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is what I'm thinking... :-D But I'm also thinking that it's a level
above Tapestry to "pull it all together". There's a difference between
"use this to build sites" and "use this to
build/manage/deploy/update/generate" sites. I'd like Tapestry itself to
continue to make the former easier/faster/better, but as an off-topic
I'm going to see what I can put together as far as the latter -
basically using Tapestry as its "back-end generator".
Howard Lewis Ship wrote:
> Hm. Wouldn't it be neat if Tapestry had a runtime environment that
> promoted the use of plugins to extend the available features. Sort of
> a hive of plugins working together, each minding its own portion of
> the application ... :-)
>
> On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> lol - Example: I use Eclipse. It's not a "source code editor / syntax
> highlighter / code completer", it's a framework that has the JDT - THAT
> does those functions. It also doesn't integrate with SVN. Subclipse does
> that. So I don't believe Tapestry should do what I'd like - I think
> there should be a framework that uses Tapestry for what Tapestry does,
> but also has more 'plugins'. If you've ever used Vignette's StoryServer
> (or others out there), it's the same concept.
>
> "do it whenever, I don't care"... yeah - never heard that before. :-D
>
> Geoff Longman wrote:
>>>> On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
>>>> You know... I think (as much as I'd like to see this just 'built in')
>>>> this is a lot like saying "I'd like my source code editor/syntax
>>>> highlighter/code completer to have source code integration" - it doesn't
>>>> belong. What you need is an "Eclipse/Idea/Pick your IDE" that integrates
>>>> the two.
>>>>
>>>>> The above paragraph is in some English-like language that look
>>>>> *exactly* like English but runs through my brain without computing
>>>>> into anything at all ;-)
>>>>> Probably the similar to the language my wife uses to mean "do it
>>>>> yesterday or I will make your life a living hell" when she says "do it
>>>>> whenever, I don't care."
>>>>> What does "I'd like my source code editor/syntax
>>>>> highlighter/code completer to have source code integration" mean?
>>>>> Geoff
>>>>
>>>> Hmmm... Yeah... That would be an interesting endeavor. Time to work out
>>>> something like this... Take that IDE to application-land.
>>>>
>>>> James Carman wrote:
>>>>>>> It might be worth looking into OSCache for this.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Brian K. Wallace [mailto:brian@transmorphix.com]
>>>>>>> Sent: Wednesday, April 26, 2006 2:20 AM
>>>>>>> To: Tapestry development
>>>>>>> Subject: Re: Tapestry 5 progress
>>>>>>>
>>>>>>> Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
>>>>>>> I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
>>>>>>> speed before 5 hits. (feed the masses and all that :-))
>>>>>>>
>>>>>>> In speaking of performance... (I'm off in dream land here, I know... but
>>>>>>> I like it there sometimes)
>>>>>>>
>>>>>>> Many moons ago, there was talk of a 'tool' /'utility' that would
>>>>>>> basically spider a Tapestry app and get all the generated HTML resulting
>>>>>>> in basically a statically generated site. This helps tremendously when
>>>>>>> you're running behind a web server that's tuned to serve static content
>>>>>>> - it's what they do and they do it pretty well with no overhead past
>>>>>>> itself (meaning no java, no db, etc). I'd like to see if we can't add
>>>>>>> some sort of 'cache' attribute to the HTML (somewhere) that would allow
>>>>>>> Tapestry to perform this type of "wait, it says to cache it - i've
>>>>>>> already generated it, I'll just grab that and use it" processing. This
>>>>>>> would also allow Tapestry to build on first access but write out the
>>>>>>> generated HTML so the next time a request comes in for it, the web
>>>>>>> server would find it first (outside the mapping for Tapestry). Granted
>>>>>>> this would only work for pages that were "cache=true" and had no dynamic
>>>>>>> components inside it, but for a lot of sites that's enough (especially
>>>>>>> outside a 'user' area). If there's a static form, submitting it would
>>>>>>> pass back to Tapestry for processing.
>>>>>>>
>>>>>>> I'd see this as only improving performance if you run Tapestry behind
>>>>>>> something like Apache. Granted, you'd get a lot of "that's not fair -
>>>>>>> you're not comparing our framework to yours if you don't hit your
>>>>>>> framework more than once when we have to hit ours every time"
>>>>>>> comments... but hey ;-)
>>>>>>>
>>>>>>> My .02
>>>>>>> Brian
>>>>>>>
>>>>>>> Howard Lewis Ship wrote:
>>>>>>>>> The basic AOP infrastructure is coming along. I expect the rest to
>>>>>>>>> ramp up pretty quickly once I get that in place, but we're still
>>>>>>>>> talking months. Maybe a useable beta by year's end.
>>>>>>>>>
>>>>>>>>> I think I predicted a big performance boost for Tapestry 4 apps vs.
>>>>>>>>> equivalent Tapestry 3 apps. I believe the difference between 4 and 5
>>>>>>>>> will be greater. In fact, I expect OGNL support to be an add on, and
>>>>>>>>> the built-in code will be an improved version of tapestry-prop (from
>>>>>>>>> Tapestry @ JavaForge). I want Tapestry to be extremely high
>>>>>>>>> performance, as one of its differentiators from JSF and Rails.
>>>>>>>>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFET7RtaCoPKRow/gARAvcKAJ9oRrgSVknYyAq7V1k9kXvZSn69egCgzueh
m8+Wpdk+ZGEbpdSTyThJpvo=
=YJFI
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by Geoff Longman <gl...@gmail.com>.
links of interest:
http://incubator.apache.org/felix/ - osgi impl currently in incubation
There also was some talk last fall about about harmony
(http://incubator.apache.org/harmony/) jumping on the osgi bandwagon
too but I'm unable to find any recent references.
Geoff
On 4/26/06, Geoff Longman <gl...@gmail.com> wrote:
> Eclipse took osgi bundles and added contributions to make Eclipse plugins.
>
> Nothing says that one can't take osgi bundles and add HM
> configurations and the services cool threaded services models there
> too.
>
> osgi has a service model already, very simple one it would be possible
> to add HMiness 'cuz ogsi does not mandate anywhere how those services
> are implemented or configured.
>
> Plus osgi has all the lifecycle, hot redeploy, provision over the wire
> stuff that HM curently lacks.
>
> The only thing that make osgi bundles challenging in the classloader model.
>
> Geoff.
>
> On 4/26/06, James Carman <ja...@carmanconsulting.com> wrote:
> > Hey, them's fightin' words. You mean it's called HiveMind?!?! :-)
> >
> >
> > -----Original Message-----
> > From: Geoff Longman [mailto:glongman@gmail.com]
> > Sent: Wednesday, April 26, 2006 2:03 PM
> > To: Tapestry development
> > Subject: Re: Tapestry 5 progress
> >
> > it's called osgi
> >
> > G
> >
> > On 4/26/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > Hm. Wouldn't it be neat if Tapestry had a runtime environment that
> > > promoted the use of plugins to extend the available features. Sort of
> > > a hive of plugins working together, each minding its own portion of
> > > the application ... :-)
> > >
> > > On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > lol - Example: I use Eclipse. It's not a "source code editor / syntax
> > > > highlighter / code completer", it's a framework that has the JDT - THAT
> > > > does those functions. It also doesn't integrate with SVN. Subclipse does
> > > > that. So I don't believe Tapestry should do what I'd like - I think
> > > > there should be a framework that uses Tapestry for what Tapestry does,
> > > > but also has more 'plugins'. If you've ever used Vignette's StoryServer
> > > > (or others out there), it's the same concept.
> > > >
> > > > "do it whenever, I don't care"... yeah - never heard that before. :-D
> > > >
> > > > Geoff Longman wrote:
> > > > > On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> > > > > You know... I think (as much as I'd like to see this just 'built in')
> > > > > this is a lot like saying "I'd like my source code editor/syntax
> > > > > highlighter/code completer to have source code integration" - it
> > doesn't
> > > > > belong. What you need is an "Eclipse/Idea/Pick your IDE" that
> > integrates
> > > > > the two.
> > > > >
> > > > >> The above paragraph is in some English-like language that look
> > > > >> *exactly* like English but runs through my brain without computing
> > > > >> into anything at all ;-)
> > > > >
> > > > >> Probably the similar to the language my wife uses to mean "do it
> > > > >> yesterday or I will make your life a living hell" when she says "do
> > it
> > > > >> whenever, I don't care."
> > > > >
> > > > >> What does "I'd like my source code editor/syntax
> > > > >> highlighter/code completer to have source code integration" mean?
> > > > >
> > > > >> Geoff
> > > > >
> > > > >
> > > > > Hmmm... Yeah... That would be an interesting endeavor. Time to work
> > out
> > > > > something like this... Take that IDE to application-land.
> > > > >
> > > > > James Carman wrote:
> > > > >>>> It might be worth looking into OSCache for this.
> > > > >>>>
> > > > >>>> -----Original Message-----
> > > > >>>> From: Brian K. Wallace [mailto:brian@transmorphix.com]
> > > > >>>> Sent: Wednesday, April 26, 2006 2:20 AM
> > > > >>>> To: Tapestry development
> > > > >>>> Subject: Re: Tapestry 5 progress
> > > > >>>>
> > > > >>>> Works for me. Plenty of growing room for 4 left anyway, right
> > Jesse? ;-)
> > > > >>>> I'm just hoping to get documentation (*ugh*) and tooling (Spindle)
> > up to
> > > > >>>> speed before 5 hits. (feed the masses and all that :-))
> > > > >>>>
> > > > >>>> In speaking of performance... (I'm off in dream land here, I
> > know... but
> > > > >>>> I like it there sometimes)
> > > > >>>>
> > > > >>>> Many moons ago, there was talk of a 'tool' /'utility' that would
> > > > >>>> basically spider a Tapestry app and get all the generated HTML
> > resulting
> > > > >>>> in basically a statically generated site. This helps tremendously
> > when
> > > > >>>> you're running behind a web server that's tuned to serve static
> > content
> > > > >>>> - it's what they do and they do it pretty well with no overhead
> > past
> > > > >>>> itself (meaning no java, no db, etc). I'd like to see if we can't
> > add
> > > > >>>> some sort of 'cache' attribute to the HTML (somewhere) that would
> > allow
> > > > >>>> Tapestry to perform this type of "wait, it says to cache it - i've
> > > > >>>> already generated it, I'll just grab that and use it" processing.
> > This
> > > > >>>> would also allow Tapestry to build on first access but write out
> > the
> > > > >>>> generated HTML so the next time a request comes in for it, the web
> > > > >>>> server would find it first (outside the mapping for Tapestry).
> > Granted
> > > > >>>> this would only work for pages that were "cache=true" and had no
> > dynamic
> > > > >>>> components inside it, but for a lot of sites that's enough
> > (especially
> > > > >>>> outside a 'user' area). If there's a static form, submitting it
> > would
> > > > >>>> pass back to Tapestry for processing.
> > > > >>>>
> > > > >>>> I'd see this as only improving performance if you run Tapestry
> > behind
> > > > >>>> something like Apache. Granted, you'd get a lot of "that's not fair
> > -
> > > > >>>> you're not comparing our framework to yours if you don't hit your
> > > > >>>> framework more than once when we have to hit ours every time"
> > > > >>>> comments... but hey ;-)
> > > > >>>>
> > > > >>>> My .02
> > > > >>>> Brian
> > > > >>>>
> > > > >>>> Howard Lewis Ship wrote:
> > > > >>>>>> The basic AOP infrastructure is coming along. I expect the rest
> > to
> > > > >>>>>> ramp up pretty quickly once I get that in place, but we're still
> > > > >>>>>> talking months. Maybe a useable beta by year's end.
> > > > >>>>>>
> > > > >>>>>> I think I predicted a big performance boost for Tapestry 4 apps
> > vs.
> > > > >>>>>> equivalent Tapestry 3 apps. I believe the difference between 4
> > and 5
> > > > >>>>>> will be greater. In fact, I expect OGNL support to be an add on,
> > and
> > > > >>>>>> the built-in code will be an improved version of tapestry-prop
> > (from
> > > > >>>>>> Tapestry @ JavaForge). I want Tapestry to be extremely high
> > > > >>>>>> performance, as one of its differentiators from JSF and Rails.
> > > > >>>>>>
> > > >
> > > > -----BEGIN PGP SIGNATURE-----
> > > > Version: GnuPG v1.2.5 (MingW32)
> > > >
> > > > iD8DBQFET7DVaCoPKRow/gARAmKhAJ9nMufXCvQOfoKYMD1z0rLydvLlSwCfdLF1
> > > > 2kVbZyicMJD9mG/fxIZDMoQ=
> > > > =ZDag
> > > > -----END PGP SIGNATURE-----
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > 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
> > >
> > >
> >
> >
> > --
> > The Spindle guy. http://spindle.sf.net
> > Blog: http://jroller.com/page/glongman
> > Other interests: http://www.squidoo.com/spaceelevator/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> The Spindle guy. http://spindle.sf.net
> Blog: http://jroller.com/page/glongman
> Other interests: http://www.squidoo.com/spaceelevator/
>
--
The Spindle guy. http://spindle.sf.net
Blog: http://jroller.com/page/glongman
Other interests: http://www.squidoo.com/spaceelevator/
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by Geoff Longman <gl...@gmail.com>.
Eclipse took osgi bundles and added contributions to make Eclipse plugins.
Nothing says that one can't take osgi bundles and add HM
configurations and the services cool threaded services models there
too.
osgi has a service model already, very simple one it would be possible
to add HMiness 'cuz ogsi does not mandate anywhere how those services
are implemented or configured.
Plus osgi has all the lifecycle, hot redeploy, provision over the wire
stuff that HM curently lacks.
The only thing that make osgi bundles challenging in the classloader model.
Geoff.
On 4/26/06, James Carman <ja...@carmanconsulting.com> wrote:
> Hey, them's fightin' words. You mean it's called HiveMind?!?! :-)
>
>
> -----Original Message-----
> From: Geoff Longman [mailto:glongman@gmail.com]
> Sent: Wednesday, April 26, 2006 2:03 PM
> To: Tapestry development
> Subject: Re: Tapestry 5 progress
>
> it's called osgi
>
> G
>
> On 4/26/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> > Hm. Wouldn't it be neat if Tapestry had a runtime environment that
> > promoted the use of plugins to extend the available features. Sort of
> > a hive of plugins working together, each minding its own portion of
> > the application ... :-)
> >
> > On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > lol - Example: I use Eclipse. It's not a "source code editor / syntax
> > > highlighter / code completer", it's a framework that has the JDT - THAT
> > > does those functions. It also doesn't integrate with SVN. Subclipse does
> > > that. So I don't believe Tapestry should do what I'd like - I think
> > > there should be a framework that uses Tapestry for what Tapestry does,
> > > but also has more 'plugins'. If you've ever used Vignette's StoryServer
> > > (or others out there), it's the same concept.
> > >
> > > "do it whenever, I don't care"... yeah - never heard that before. :-D
> > >
> > > Geoff Longman wrote:
> > > > On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> > > > You know... I think (as much as I'd like to see this just 'built in')
> > > > this is a lot like saying "I'd like my source code editor/syntax
> > > > highlighter/code completer to have source code integration" - it
> doesn't
> > > > belong. What you need is an "Eclipse/Idea/Pick your IDE" that
> integrates
> > > > the two.
> > > >
> > > >> The above paragraph is in some English-like language that look
> > > >> *exactly* like English but runs through my brain without computing
> > > >> into anything at all ;-)
> > > >
> > > >> Probably the similar to the language my wife uses to mean "do it
> > > >> yesterday or I will make your life a living hell" when she says "do
> it
> > > >> whenever, I don't care."
> > > >
> > > >> What does "I'd like my source code editor/syntax
> > > >> highlighter/code completer to have source code integration" mean?
> > > >
> > > >> Geoff
> > > >
> > > >
> > > > Hmmm... Yeah... That would be an interesting endeavor. Time to work
> out
> > > > something like this... Take that IDE to application-land.
> > > >
> > > > James Carman wrote:
> > > >>>> It might be worth looking into OSCache for this.
> > > >>>>
> > > >>>> -----Original Message-----
> > > >>>> From: Brian K. Wallace [mailto:brian@transmorphix.com]
> > > >>>> Sent: Wednesday, April 26, 2006 2:20 AM
> > > >>>> To: Tapestry development
> > > >>>> Subject: Re: Tapestry 5 progress
> > > >>>>
> > > >>>> Works for me. Plenty of growing room for 4 left anyway, right
> Jesse? ;-)
> > > >>>> I'm just hoping to get documentation (*ugh*) and tooling (Spindle)
> up to
> > > >>>> speed before 5 hits. (feed the masses and all that :-))
> > > >>>>
> > > >>>> In speaking of performance... (I'm off in dream land here, I
> know... but
> > > >>>> I like it there sometimes)
> > > >>>>
> > > >>>> Many moons ago, there was talk of a 'tool' /'utility' that would
> > > >>>> basically spider a Tapestry app and get all the generated HTML
> resulting
> > > >>>> in basically a statically generated site. This helps tremendously
> when
> > > >>>> you're running behind a web server that's tuned to serve static
> content
> > > >>>> - it's what they do and they do it pretty well with no overhead
> past
> > > >>>> itself (meaning no java, no db, etc). I'd like to see if we can't
> add
> > > >>>> some sort of 'cache' attribute to the HTML (somewhere) that would
> allow
> > > >>>> Tapestry to perform this type of "wait, it says to cache it - i've
> > > >>>> already generated it, I'll just grab that and use it" processing.
> This
> > > >>>> would also allow Tapestry to build on first access but write out
> the
> > > >>>> generated HTML so the next time a request comes in for it, the web
> > > >>>> server would find it first (outside the mapping for Tapestry).
> Granted
> > > >>>> this would only work for pages that were "cache=true" and had no
> dynamic
> > > >>>> components inside it, but for a lot of sites that's enough
> (especially
> > > >>>> outside a 'user' area). If there's a static form, submitting it
> would
> > > >>>> pass back to Tapestry for processing.
> > > >>>>
> > > >>>> I'd see this as only improving performance if you run Tapestry
> behind
> > > >>>> something like Apache. Granted, you'd get a lot of "that's not fair
> -
> > > >>>> you're not comparing our framework to yours if you don't hit your
> > > >>>> framework more than once when we have to hit ours every time"
> > > >>>> comments... but hey ;-)
> > > >>>>
> > > >>>> My .02
> > > >>>> Brian
> > > >>>>
> > > >>>> Howard Lewis Ship wrote:
> > > >>>>>> The basic AOP infrastructure is coming along. I expect the rest
> to
> > > >>>>>> ramp up pretty quickly once I get that in place, but we're still
> > > >>>>>> talking months. Maybe a useable beta by year's end.
> > > >>>>>>
> > > >>>>>> I think I predicted a big performance boost for Tapestry 4 apps
> vs.
> > > >>>>>> equivalent Tapestry 3 apps. I believe the difference between 4
> and 5
> > > >>>>>> will be greater. In fact, I expect OGNL support to be an add on,
> and
> > > >>>>>> the built-in code will be an improved version of tapestry-prop
> (from
> > > >>>>>> Tapestry @ JavaForge). I want Tapestry to be extremely high
> > > >>>>>> performance, as one of its differentiators from JSF and Rails.
> > > >>>>>>
> > >
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.2.5 (MingW32)
> > >
> > > iD8DBQFET7DVaCoPKRow/gARAmKhAJ9nMufXCvQOfoKYMD1z0rLydvLlSwCfdLF1
> > > 2kVbZyicMJD9mG/fxIZDMoQ=
> > > =ZDag
> > > -----END PGP SIGNATURE-----
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > --
> > 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
> >
> >
>
>
> --
> The Spindle guy. http://spindle.sf.net
> Blog: http://jroller.com/page/glongman
> Other interests: http://www.squidoo.com/spaceelevator/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
The Spindle guy. http://spindle.sf.net
Blog: http://jroller.com/page/glongman
Other interests: http://www.squidoo.com/spaceelevator/
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Oh, I was just waiting for a reply like that one :-)
I could actually see both working with different parts of a 'system' in
my head... I think I'll see what I can put together as far as a concept
and host it so what I'm thinking a) doesn't get lost, b) doesn't take up
too much dev-thread cycles (because I could probably go on forever about
this) and c) gets other eyes pointing out flaws in my ideas.
James Carman wrote:
> Hey, them's fightin' words. You mean it's called HiveMind?!?! :-)
>
>
> -----Original Message-----
> From: Geoff Longman [mailto:glongman@gmail.com]
> Sent: Wednesday, April 26, 2006 2:03 PM
> To: Tapestry development
> Subject: Re: Tapestry 5 progress
>
> it's called osgi
>
> G
>
> On 4/26/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>> Hm. Wouldn't it be neat if Tapestry had a runtime environment that
>> promoted the use of plugins to extend the available features. Sort of
>> a hive of plugins working together, each minding its own portion of
>> the application ... :-)
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFET7fHaCoPKRow/gARAkahAKCX/SsvqkvwGaXCsp/FQIMg7yr2rQCg6ET+
NLAAxZwzsWhuZXKcsgwIudc=
=2Cni
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: Tapestry 5 progress
Posted by James Carman <ja...@carmanconsulting.com>.
Hey, them's fightin' words. You mean it's called HiveMind?!?! :-)
-----Original Message-----
From: Geoff Longman [mailto:glongman@gmail.com]
Sent: Wednesday, April 26, 2006 2:03 PM
To: Tapestry development
Subject: Re: Tapestry 5 progress
it's called osgi
G
On 4/26/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> Hm. Wouldn't it be neat if Tapestry had a runtime environment that
> promoted the use of plugins to extend the available features. Sort of
> a hive of plugins working together, each minding its own portion of
> the application ... :-)
>
> On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > lol - Example: I use Eclipse. It's not a "source code editor / syntax
> > highlighter / code completer", it's a framework that has the JDT - THAT
> > does those functions. It also doesn't integrate with SVN. Subclipse does
> > that. So I don't believe Tapestry should do what I'd like - I think
> > there should be a framework that uses Tapestry for what Tapestry does,
> > but also has more 'plugins'. If you've ever used Vignette's StoryServer
> > (or others out there), it's the same concept.
> >
> > "do it whenever, I don't care"... yeah - never heard that before. :-D
> >
> > Geoff Longman wrote:
> > > On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> > > You know... I think (as much as I'd like to see this just 'built in')
> > > this is a lot like saying "I'd like my source code editor/syntax
> > > highlighter/code completer to have source code integration" - it
doesn't
> > > belong. What you need is an "Eclipse/Idea/Pick your IDE" that
integrates
> > > the two.
> > >
> > >> The above paragraph is in some English-like language that look
> > >> *exactly* like English but runs through my brain without computing
> > >> into anything at all ;-)
> > >
> > >> Probably the similar to the language my wife uses to mean "do it
> > >> yesterday or I will make your life a living hell" when she says "do
it
> > >> whenever, I don't care."
> > >
> > >> What does "I'd like my source code editor/syntax
> > >> highlighter/code completer to have source code integration" mean?
> > >
> > >> Geoff
> > >
> > >
> > > Hmmm... Yeah... That would be an interesting endeavor. Time to work
out
> > > something like this... Take that IDE to application-land.
> > >
> > > James Carman wrote:
> > >>>> It might be worth looking into OSCache for this.
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Brian K. Wallace [mailto:brian@transmorphix.com]
> > >>>> Sent: Wednesday, April 26, 2006 2:20 AM
> > >>>> To: Tapestry development
> > >>>> Subject: Re: Tapestry 5 progress
> > >>>>
> > >>>> Works for me. Plenty of growing room for 4 left anyway, right
Jesse? ;-)
> > >>>> I'm just hoping to get documentation (*ugh*) and tooling (Spindle)
up to
> > >>>> speed before 5 hits. (feed the masses and all that :-))
> > >>>>
> > >>>> In speaking of performance... (I'm off in dream land here, I
know... but
> > >>>> I like it there sometimes)
> > >>>>
> > >>>> Many moons ago, there was talk of a 'tool' /'utility' that would
> > >>>> basically spider a Tapestry app and get all the generated HTML
resulting
> > >>>> in basically a statically generated site. This helps tremendously
when
> > >>>> you're running behind a web server that's tuned to serve static
content
> > >>>> - it's what they do and they do it pretty well with no overhead
past
> > >>>> itself (meaning no java, no db, etc). I'd like to see if we can't
add
> > >>>> some sort of 'cache' attribute to the HTML (somewhere) that would
allow
> > >>>> Tapestry to perform this type of "wait, it says to cache it - i've
> > >>>> already generated it, I'll just grab that and use it" processing.
This
> > >>>> would also allow Tapestry to build on first access but write out
the
> > >>>> generated HTML so the next time a request comes in for it, the web
> > >>>> server would find it first (outside the mapping for Tapestry).
Granted
> > >>>> this would only work for pages that were "cache=true" and had no
dynamic
> > >>>> components inside it, but for a lot of sites that's enough
(especially
> > >>>> outside a 'user' area). If there's a static form, submitting it
would
> > >>>> pass back to Tapestry for processing.
> > >>>>
> > >>>> I'd see this as only improving performance if you run Tapestry
behind
> > >>>> something like Apache. Granted, you'd get a lot of "that's not fair
-
> > >>>> you're not comparing our framework to yours if you don't hit your
> > >>>> framework more than once when we have to hit ours every time"
> > >>>> comments... but hey ;-)
> > >>>>
> > >>>> My .02
> > >>>> Brian
> > >>>>
> > >>>> Howard Lewis Ship wrote:
> > >>>>>> The basic AOP infrastructure is coming along. I expect the rest
to
> > >>>>>> ramp up pretty quickly once I get that in place, but we're still
> > >>>>>> talking months. Maybe a useable beta by year's end.
> > >>>>>>
> > >>>>>> I think I predicted a big performance boost for Tapestry 4 apps
vs.
> > >>>>>> equivalent Tapestry 3 apps. I believe the difference between 4
and 5
> > >>>>>> will be greater. In fact, I expect OGNL support to be an add on,
and
> > >>>>>> the built-in code will be an improved version of tapestry-prop
(from
> > >>>>>> Tapestry @ JavaForge). I want Tapestry to be extremely high
> > >>>>>> performance, as one of its differentiators from JSF and Rails.
> > >>>>>>
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.5 (MingW32)
> >
> > iD8DBQFET7DVaCoPKRow/gARAmKhAJ9nMufXCvQOfoKYMD1z0rLydvLlSwCfdLF1
> > 2kVbZyicMJD9mG/fxIZDMoQ=
> > =ZDag
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> 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
>
>
--
The Spindle guy. http://spindle.sf.net
Blog: http://jroller.com/page/glongman
Other interests: http://www.squidoo.com/spaceelevator/
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by Geoff Longman <gl...@gmail.com>.
it's called osgi
G
On 4/26/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> Hm. Wouldn't it be neat if Tapestry had a runtime environment that
> promoted the use of plugins to extend the available features. Sort of
> a hive of plugins working together, each minding its own portion of
> the application ... :-)
>
> On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > lol - Example: I use Eclipse. It's not a "source code editor / syntax
> > highlighter / code completer", it's a framework that has the JDT - THAT
> > does those functions. It also doesn't integrate with SVN. Subclipse does
> > that. So I don't believe Tapestry should do what I'd like - I think
> > there should be a framework that uses Tapestry for what Tapestry does,
> > but also has more 'plugins'. If you've ever used Vignette's StoryServer
> > (or others out there), it's the same concept.
> >
> > "do it whenever, I don't care"... yeah - never heard that before. :-D
> >
> > Geoff Longman wrote:
> > > On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> > > You know... I think (as much as I'd like to see this just 'built in')
> > > this is a lot like saying "I'd like my source code editor/syntax
> > > highlighter/code completer to have source code integration" - it doesn't
> > > belong. What you need is an "Eclipse/Idea/Pick your IDE" that integrates
> > > the two.
> > >
> > >> The above paragraph is in some English-like language that look
> > >> *exactly* like English but runs through my brain without computing
> > >> into anything at all ;-)
> > >
> > >> Probably the similar to the language my wife uses to mean "do it
> > >> yesterday or I will make your life a living hell" when she says "do it
> > >> whenever, I don't care."
> > >
> > >> What does "I'd like my source code editor/syntax
> > >> highlighter/code completer to have source code integration" mean?
> > >
> > >> Geoff
> > >
> > >
> > > Hmmm... Yeah... That would be an interesting endeavor. Time to work out
> > > something like this... Take that IDE to application-land.
> > >
> > > James Carman wrote:
> > >>>> It might be worth looking into OSCache for this.
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Brian K. Wallace [mailto:brian@transmorphix.com]
> > >>>> Sent: Wednesday, April 26, 2006 2:20 AM
> > >>>> To: Tapestry development
> > >>>> Subject: Re: Tapestry 5 progress
> > >>>>
> > >>>> Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
> > >>>> I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
> > >>>> speed before 5 hits. (feed the masses and all that :-))
> > >>>>
> > >>>> In speaking of performance... (I'm off in dream land here, I know... but
> > >>>> I like it there sometimes)
> > >>>>
> > >>>> Many moons ago, there was talk of a 'tool' /'utility' that would
> > >>>> basically spider a Tapestry app and get all the generated HTML resulting
> > >>>> in basically a statically generated site. This helps tremendously when
> > >>>> you're running behind a web server that's tuned to serve static content
> > >>>> - it's what they do and they do it pretty well with no overhead past
> > >>>> itself (meaning no java, no db, etc). I'd like to see if we can't add
> > >>>> some sort of 'cache' attribute to the HTML (somewhere) that would allow
> > >>>> Tapestry to perform this type of "wait, it says to cache it - i've
> > >>>> already generated it, I'll just grab that and use it" processing. This
> > >>>> would also allow Tapestry to build on first access but write out the
> > >>>> generated HTML so the next time a request comes in for it, the web
> > >>>> server would find it first (outside the mapping for Tapestry). Granted
> > >>>> this would only work for pages that were "cache=true" and had no dynamic
> > >>>> components inside it, but for a lot of sites that's enough (especially
> > >>>> outside a 'user' area). If there's a static form, submitting it would
> > >>>> pass back to Tapestry for processing.
> > >>>>
> > >>>> I'd see this as only improving performance if you run Tapestry behind
> > >>>> something like Apache. Granted, you'd get a lot of "that's not fair -
> > >>>> you're not comparing our framework to yours if you don't hit your
> > >>>> framework more than once when we have to hit ours every time"
> > >>>> comments... but hey ;-)
> > >>>>
> > >>>> My .02
> > >>>> Brian
> > >>>>
> > >>>> Howard Lewis Ship wrote:
> > >>>>>> The basic AOP infrastructure is coming along. I expect the rest to
> > >>>>>> ramp up pretty quickly once I get that in place, but we're still
> > >>>>>> talking months. Maybe a useable beta by year's end.
> > >>>>>>
> > >>>>>> I think I predicted a big performance boost for Tapestry 4 apps vs.
> > >>>>>> equivalent Tapestry 3 apps. I believe the difference between 4 and 5
> > >>>>>> will be greater. In fact, I expect OGNL support to be an add on, and
> > >>>>>> the built-in code will be an improved version of tapestry-prop (from
> > >>>>>> Tapestry @ JavaForge). I want Tapestry to be extremely high
> > >>>>>> performance, as one of its differentiators from JSF and Rails.
> > >>>>>>
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.5 (MingW32)
> >
> > iD8DBQFET7DVaCoPKRow/gARAmKhAJ9nMufXCvQOfoKYMD1z0rLydvLlSwCfdLF1
> > 2kVbZyicMJD9mG/fxIZDMoQ=
> > =ZDag
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> 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
>
>
--
The Spindle guy. http://spindle.sf.net
Blog: http://jroller.com/page/glongman
Other interests: http://www.squidoo.com/spaceelevator/
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by Howard Lewis Ship <hl...@gmail.com>.
Hm. Wouldn't it be neat if Tapestry had a runtime environment that
promoted the use of plugins to extend the available features. Sort of
a hive of plugins working together, each minding its own portion of
the application ... :-)
On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> lol - Example: I use Eclipse. It's not a "source code editor / syntax
> highlighter / code completer", it's a framework that has the JDT - THAT
> does those functions. It also doesn't integrate with SVN. Subclipse does
> that. So I don't believe Tapestry should do what I'd like - I think
> there should be a framework that uses Tapestry for what Tapestry does,
> but also has more 'plugins'. If you've ever used Vignette's StoryServer
> (or others out there), it's the same concept.
>
> "do it whenever, I don't care"... yeah - never heard that before. :-D
>
> Geoff Longman wrote:
> > On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> > You know... I think (as much as I'd like to see this just 'built in')
> > this is a lot like saying "I'd like my source code editor/syntax
> > highlighter/code completer to have source code integration" - it doesn't
> > belong. What you need is an "Eclipse/Idea/Pick your IDE" that integrates
> > the two.
> >
> >> The above paragraph is in some English-like language that look
> >> *exactly* like English but runs through my brain without computing
> >> into anything at all ;-)
> >
> >> Probably the similar to the language my wife uses to mean "do it
> >> yesterday or I will make your life a living hell" when she says "do it
> >> whenever, I don't care."
> >
> >> What does "I'd like my source code editor/syntax
> >> highlighter/code completer to have source code integration" mean?
> >
> >> Geoff
> >
> >
> > Hmmm... Yeah... That would be an interesting endeavor. Time to work out
> > something like this... Take that IDE to application-land.
> >
> > James Carman wrote:
> >>>> It might be worth looking into OSCache for this.
> >>>>
> >>>> -----Original Message-----
> >>>> From: Brian K. Wallace [mailto:brian@transmorphix.com]
> >>>> Sent: Wednesday, April 26, 2006 2:20 AM
> >>>> To: Tapestry development
> >>>> Subject: Re: Tapestry 5 progress
> >>>>
> >>>> Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
> >>>> I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
> >>>> speed before 5 hits. (feed the masses and all that :-))
> >>>>
> >>>> In speaking of performance... (I'm off in dream land here, I know... but
> >>>> I like it there sometimes)
> >>>>
> >>>> Many moons ago, there was talk of a 'tool' /'utility' that would
> >>>> basically spider a Tapestry app and get all the generated HTML resulting
> >>>> in basically a statically generated site. This helps tremendously when
> >>>> you're running behind a web server that's tuned to serve static content
> >>>> - it's what they do and they do it pretty well with no overhead past
> >>>> itself (meaning no java, no db, etc). I'd like to see if we can't add
> >>>> some sort of 'cache' attribute to the HTML (somewhere) that would allow
> >>>> Tapestry to perform this type of "wait, it says to cache it - i've
> >>>> already generated it, I'll just grab that and use it" processing. This
> >>>> would also allow Tapestry to build on first access but write out the
> >>>> generated HTML so the next time a request comes in for it, the web
> >>>> server would find it first (outside the mapping for Tapestry). Granted
> >>>> this would only work for pages that were "cache=true" and had no dynamic
> >>>> components inside it, but for a lot of sites that's enough (especially
> >>>> outside a 'user' area). If there's a static form, submitting it would
> >>>> pass back to Tapestry for processing.
> >>>>
> >>>> I'd see this as only improving performance if you run Tapestry behind
> >>>> something like Apache. Granted, you'd get a lot of "that's not fair -
> >>>> you're not comparing our framework to yours if you don't hit your
> >>>> framework more than once when we have to hit ours every time"
> >>>> comments... but hey ;-)
> >>>>
> >>>> My .02
> >>>> Brian
> >>>>
> >>>> Howard Lewis Ship wrote:
> >>>>>> The basic AOP infrastructure is coming along. I expect the rest to
> >>>>>> ramp up pretty quickly once I get that in place, but we're still
> >>>>>> talking months. Maybe a useable beta by year's end.
> >>>>>>
> >>>>>> I think I predicted a big performance boost for Tapestry 4 apps vs.
> >>>>>> equivalent Tapestry 3 apps. I believe the difference between 4 and 5
> >>>>>> will be greater. In fact, I expect OGNL support to be an add on, and
> >>>>>> the built-in code will be an improved version of tapestry-prop (from
> >>>>>> Tapestry @ JavaForge). I want Tapestry to be extremely high
> >>>>>> performance, as one of its differentiators from JSF and Rails.
> >>>>>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
>
> iD8DBQFET7DVaCoPKRow/gARAmKhAJ9nMufXCvQOfoKYMD1z0rLydvLlSwCfdLF1
> 2kVbZyicMJD9mG/fxIZDMoQ=
> =ZDag
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
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: Tapestry 5 progress
Posted by James Carman <ja...@carmanconsulting.com>.
Oh, I see what you mean. But, an application generator tool might have
these "plugins" registered with it so that it can ask the user what features
they want enabled ("do you want autowire enabled?"). Then, it'll splat the
appropriate jar files down in the /WEB-INF/lib directory of the generated
application. Of course, we'd need a cool way to let them specify the
contributions without necessarily editing their hivemodule.xml file.
-----Original Message-----
From: Brian K. Wallace [mailto:brian@transmorphix.com]
Sent: Wednesday, April 26, 2006 1:58 PM
To: Tapestry development
Subject: Re: Tapestry 5 progress
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I like this as far as making Tapestry 'better', but I think I'm focusing
on "higher level" than directly using Tapestry. [see other reply to
Howard's reply - same topic]
James Carman wrote:
> Well, that's kind of what is being put together in the "tapestry" project
at
> JavaForge, a library of "drop-in jars" for Tapestry. The idea is that
once
> you drop in the jar file, it automatically binds itself into the framework
> via HiveMind and contributions to configuration points or overriding
service
> implementations. Maybe we can work on a caching module which would enable
> itself once dropped into the classpath.
>
>
>
> -----Original Message-----
> From: Brian K. Wallace [mailto:brian@transmorphix.com]
> Sent: Wednesday, April 26, 2006 1:42 PM
> To: Tapestry development
> Subject: Re: Tapestry 5 progress
>
> lol - Example: I use Eclipse. It's not a "source code editor / syntax
> highlighter / code completer", it's a framework that has the JDT - THAT
> does those functions. It also doesn't integrate with SVN. Subclipse does
> that. So I don't believe Tapestry should do what I'd like - I think
> there should be a framework that uses Tapestry for what Tapestry does,
> but also has more 'plugins'. If you've ever used Vignette's StoryServer
> (or others out there), it's the same concept.
>
> "do it whenever, I don't care"... yeah - never heard that before. :-D
>
> Geoff Longman wrote:
>>> On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
>>> You know... I think (as much as I'd like to see this just 'built in')
>>> this is a lot like saying "I'd like my source code editor/syntax
>>> highlighter/code completer to have source code integration" - it doesn't
>>> belong. What you need is an "Eclipse/Idea/Pick your IDE" that integrates
>>> the two.
>>>
>>>> The above paragraph is in some English-like language that look
>>>> *exactly* like English but runs through my brain without computing
>>>> into anything at all ;-)
>>>> Probably the similar to the language my wife uses to mean "do it
>>>> yesterday or I will make your life a living hell" when she says "do it
>>>> whenever, I don't care."
>>>> What does "I'd like my source code editor/syntax
>>>> highlighter/code completer to have source code integration" mean?
>>>> Geoff
>>>
>>> Hmmm... Yeah... That would be an interesting endeavor. Time to work out
>>> something like this... Take that IDE to application-land.
>>>
>>> James Carman wrote:
>>>>>> It might be worth looking into OSCache for this.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Brian K. Wallace [mailto:brian@transmorphix.com]
>>>>>> Sent: Wednesday, April 26, 2006 2:20 AM
>>>>>> To: Tapestry development
>>>>>> Subject: Re: Tapestry 5 progress
>>>>>>
>>>>>> Works for me. Plenty of growing room for 4 left anyway, right Jesse?
> ;-)
>>>>>> I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up
> to
>>>>>> speed before 5 hits. (feed the masses and all that :-))
>>>>>>
>>>>>> In speaking of performance... (I'm off in dream land here, I know...
> but
>>>>>> I like it there sometimes)
>>>>>>
>>>>>> Many moons ago, there was talk of a 'tool' /'utility' that would
>>>>>> basically spider a Tapestry app and get all the generated HTML
> resulting
>>>>>> in basically a statically generated site. This helps tremendously
when
>>>>>> you're running behind a web server that's tuned to serve static
content
>>>>>> - it's what they do and they do it pretty well with no overhead past
>>>>>> itself (meaning no java, no db, etc). I'd like to see if we can't add
>>>>>> some sort of 'cache' attribute to the HTML (somewhere) that would
allow
>>>>>> Tapestry to perform this type of "wait, it says to cache it - i've
>>>>>> already generated it, I'll just grab that and use it" processing.
This
>>>>>> would also allow Tapestry to build on first access but write out the
>>>>>> generated HTML so the next time a request comes in for it, the web
>>>>>> server would find it first (outside the mapping for Tapestry).
Granted
>>>>>> this would only work for pages that were "cache=true" and had no
> dynamic
>>>>>> components inside it, but for a lot of sites that's enough
(especially
>>>>>> outside a 'user' area). If there's a static form, submitting it would
>>>>>> pass back to Tapestry for processing.
>>>>>>
>>>>>> I'd see this as only improving performance if you run Tapestry behind
>>>>>> something like Apache. Granted, you'd get a lot of "that's not fair -
>>>>>> you're not comparing our framework to yours if you don't hit your
>>>>>> framework more than once when we have to hit ours every time"
>>>>>> comments... but hey ;-)
>>>>>>
>>>>>> My .02
>>>>>> Brian
>>>>>>
>>>>>> Howard Lewis Ship wrote:
>>>>>>>> The basic AOP infrastructure is coming along. I expect the rest to
>>>>>>>> ramp up pretty quickly once I get that in place, but we're still
>>>>>>>> talking months. Maybe a useable beta by year's end.
>>>>>>>>
>>>>>>>> I think I predicted a big performance boost for Tapestry 4 apps vs.
>>>>>>>> equivalent Tapestry 3 apps. I believe the difference between 4 and
5
>>>>>>>> will be greater. In fact, I expect OGNL support to be an add on,
and
>>>>>>>> the built-in code will be an improved version of tapestry-prop
(from
>>>>>>>> Tapestry @ JavaForge). I want Tapestry to be extremely high
>>>>>>>> performance, as one of its differentiators from JSF and Rails.
>>>>>>>>
>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
- ---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFET7TEaCoPKRow/gARAj/XAKDTxrEK/LqFUKanNKAp9+XX8kW+hQCfRw/A
3FLroGSnxc21so6nCZt+/eA=
=Pmt7
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I like this as far as making Tapestry 'better', but I think I'm focusing
on "higher level" than directly using Tapestry. [see other reply to
Howard's reply - same topic]
James Carman wrote:
> Well, that's kind of what is being put together in the "tapestry" project at
> JavaForge, a library of "drop-in jars" for Tapestry. The idea is that once
> you drop in the jar file, it automatically binds itself into the framework
> via HiveMind and contributions to configuration points or overriding service
> implementations. Maybe we can work on a caching module which would enable
> itself once dropped into the classpath.
>
>
>
> -----Original Message-----
> From: Brian K. Wallace [mailto:brian@transmorphix.com]
> Sent: Wednesday, April 26, 2006 1:42 PM
> To: Tapestry development
> Subject: Re: Tapestry 5 progress
>
> lol - Example: I use Eclipse. It's not a "source code editor / syntax
> highlighter / code completer", it's a framework that has the JDT - THAT
> does those functions. It also doesn't integrate with SVN. Subclipse does
> that. So I don't believe Tapestry should do what I'd like - I think
> there should be a framework that uses Tapestry for what Tapestry does,
> but also has more 'plugins'. If you've ever used Vignette's StoryServer
> (or others out there), it's the same concept.
>
> "do it whenever, I don't care"... yeah - never heard that before. :-D
>
> Geoff Longman wrote:
>>> On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
>>> You know... I think (as much as I'd like to see this just 'built in')
>>> this is a lot like saying "I'd like my source code editor/syntax
>>> highlighter/code completer to have source code integration" - it doesn't
>>> belong. What you need is an "Eclipse/Idea/Pick your IDE" that integrates
>>> the two.
>>>
>>>> The above paragraph is in some English-like language that look
>>>> *exactly* like English but runs through my brain without computing
>>>> into anything at all ;-)
>>>> Probably the similar to the language my wife uses to mean "do it
>>>> yesterday or I will make your life a living hell" when she says "do it
>>>> whenever, I don't care."
>>>> What does "I'd like my source code editor/syntax
>>>> highlighter/code completer to have source code integration" mean?
>>>> Geoff
>>>
>>> Hmmm... Yeah... That would be an interesting endeavor. Time to work out
>>> something like this... Take that IDE to application-land.
>>>
>>> James Carman wrote:
>>>>>> It might be worth looking into OSCache for this.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Brian K. Wallace [mailto:brian@transmorphix.com]
>>>>>> Sent: Wednesday, April 26, 2006 2:20 AM
>>>>>> To: Tapestry development
>>>>>> Subject: Re: Tapestry 5 progress
>>>>>>
>>>>>> Works for me. Plenty of growing room for 4 left anyway, right Jesse?
> ;-)
>>>>>> I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up
> to
>>>>>> speed before 5 hits. (feed the masses and all that :-))
>>>>>>
>>>>>> In speaking of performance... (I'm off in dream land here, I know...
> but
>>>>>> I like it there sometimes)
>>>>>>
>>>>>> Many moons ago, there was talk of a 'tool' /'utility' that would
>>>>>> basically spider a Tapestry app and get all the generated HTML
> resulting
>>>>>> in basically a statically generated site. This helps tremendously when
>>>>>> you're running behind a web server that's tuned to serve static content
>>>>>> - it's what they do and they do it pretty well with no overhead past
>>>>>> itself (meaning no java, no db, etc). I'd like to see if we can't add
>>>>>> some sort of 'cache' attribute to the HTML (somewhere) that would allow
>>>>>> Tapestry to perform this type of "wait, it says to cache it - i've
>>>>>> already generated it, I'll just grab that and use it" processing. This
>>>>>> would also allow Tapestry to build on first access but write out the
>>>>>> generated HTML so the next time a request comes in for it, the web
>>>>>> server would find it first (outside the mapping for Tapestry). Granted
>>>>>> this would only work for pages that were "cache=true" and had no
> dynamic
>>>>>> components inside it, but for a lot of sites that's enough (especially
>>>>>> outside a 'user' area). If there's a static form, submitting it would
>>>>>> pass back to Tapestry for processing.
>>>>>>
>>>>>> I'd see this as only improving performance if you run Tapestry behind
>>>>>> something like Apache. Granted, you'd get a lot of "that's not fair -
>>>>>> you're not comparing our framework to yours if you don't hit your
>>>>>> framework more than once when we have to hit ours every time"
>>>>>> comments... but hey ;-)
>>>>>>
>>>>>> My .02
>>>>>> Brian
>>>>>>
>>>>>> Howard Lewis Ship wrote:
>>>>>>>> The basic AOP infrastructure is coming along. I expect the rest to
>>>>>>>> ramp up pretty quickly once I get that in place, but we're still
>>>>>>>> talking months. Maybe a useable beta by year's end.
>>>>>>>>
>>>>>>>> I think I predicted a big performance boost for Tapestry 4 apps vs.
>>>>>>>> equivalent Tapestry 3 apps. I believe the difference between 4 and 5
>>>>>>>> will be greater. In fact, I expect OGNL support to be an add on, and
>>>>>>>> the built-in code will be an improved version of tapestry-prop (from
>>>>>>>> Tapestry @ JavaForge). I want Tapestry to be extremely high
>>>>>>>> performance, as one of its differentiators from JSF and Rails.
>>>>>>>>
>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
- ---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFET7TEaCoPKRow/gARAj/XAKDTxrEK/LqFUKanNKAp9+XX8kW+hQCfRw/A
3FLroGSnxc21so6nCZt+/eA=
=Pmt7
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: Tapestry 5 progress
Posted by James Carman <ja...@carmanconsulting.com>.
Well, that's kind of what is being put together in the "tapestry" project at
JavaForge, a library of "drop-in jars" for Tapestry. The idea is that once
you drop in the jar file, it automatically binds itself into the framework
via HiveMind and contributions to configuration points or overriding service
implementations. Maybe we can work on a caching module which would enable
itself once dropped into the classpath.
-----Original Message-----
From: Brian K. Wallace [mailto:brian@transmorphix.com]
Sent: Wednesday, April 26, 2006 1:42 PM
To: Tapestry development
Subject: Re: Tapestry 5 progress
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
lol - Example: I use Eclipse. It's not a "source code editor / syntax
highlighter / code completer", it's a framework that has the JDT - THAT
does those functions. It also doesn't integrate with SVN. Subclipse does
that. So I don't believe Tapestry should do what I'd like - I think
there should be a framework that uses Tapestry for what Tapestry does,
but also has more 'plugins'. If you've ever used Vignette's StoryServer
(or others out there), it's the same concept.
"do it whenever, I don't care"... yeah - never heard that before. :-D
Geoff Longman wrote:
> On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> You know... I think (as much as I'd like to see this just 'built in')
> this is a lot like saying "I'd like my source code editor/syntax
> highlighter/code completer to have source code integration" - it doesn't
> belong. What you need is an "Eclipse/Idea/Pick your IDE" that integrates
> the two.
>
>> The above paragraph is in some English-like language that look
>> *exactly* like English but runs through my brain without computing
>> into anything at all ;-)
>
>> Probably the similar to the language my wife uses to mean "do it
>> yesterday or I will make your life a living hell" when she says "do it
>> whenever, I don't care."
>
>> What does "I'd like my source code editor/syntax
>> highlighter/code completer to have source code integration" mean?
>
>> Geoff
>
>
> Hmmm... Yeah... That would be an interesting endeavor. Time to work out
> something like this... Take that IDE to application-land.
>
> James Carman wrote:
>>>> It might be worth looking into OSCache for this.
>>>>
>>>> -----Original Message-----
>>>> From: Brian K. Wallace [mailto:brian@transmorphix.com]
>>>> Sent: Wednesday, April 26, 2006 2:20 AM
>>>> To: Tapestry development
>>>> Subject: Re: Tapestry 5 progress
>>>>
>>>> Works for me. Plenty of growing room for 4 left anyway, right Jesse?
;-)
>>>> I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up
to
>>>> speed before 5 hits. (feed the masses and all that :-))
>>>>
>>>> In speaking of performance... (I'm off in dream land here, I know...
but
>>>> I like it there sometimes)
>>>>
>>>> Many moons ago, there was talk of a 'tool' /'utility' that would
>>>> basically spider a Tapestry app and get all the generated HTML
resulting
>>>> in basically a statically generated site. This helps tremendously when
>>>> you're running behind a web server that's tuned to serve static content
>>>> - it's what they do and they do it pretty well with no overhead past
>>>> itself (meaning no java, no db, etc). I'd like to see if we can't add
>>>> some sort of 'cache' attribute to the HTML (somewhere) that would allow
>>>> Tapestry to perform this type of "wait, it says to cache it - i've
>>>> already generated it, I'll just grab that and use it" processing. This
>>>> would also allow Tapestry to build on first access but write out the
>>>> generated HTML so the next time a request comes in for it, the web
>>>> server would find it first (outside the mapping for Tapestry). Granted
>>>> this would only work for pages that were "cache=true" and had no
dynamic
>>>> components inside it, but for a lot of sites that's enough (especially
>>>> outside a 'user' area). If there's a static form, submitting it would
>>>> pass back to Tapestry for processing.
>>>>
>>>> I'd see this as only improving performance if you run Tapestry behind
>>>> something like Apache. Granted, you'd get a lot of "that's not fair -
>>>> you're not comparing our framework to yours if you don't hit your
>>>> framework more than once when we have to hit ours every time"
>>>> comments... but hey ;-)
>>>>
>>>> My .02
>>>> Brian
>>>>
>>>> Howard Lewis Ship wrote:
>>>>>> The basic AOP infrastructure is coming along. I expect the rest to
>>>>>> ramp up pretty quickly once I get that in place, but we're still
>>>>>> talking months. Maybe a useable beta by year's end.
>>>>>>
>>>>>> I think I predicted a big performance boost for Tapestry 4 apps vs.
>>>>>> equivalent Tapestry 3 apps. I believe the difference between 4 and 5
>>>>>> will be greater. In fact, I expect OGNL support to be an add on, and
>>>>>> the built-in code will be an improved version of tapestry-prop (from
>>>>>> Tapestry @ JavaForge). I want Tapestry to be extremely high
>>>>>> performance, as one of its differentiators from JSF and Rails.
>>>>>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFET7DVaCoPKRow/gARAmKhAJ9nMufXCvQOfoKYMD1z0rLydvLlSwCfdLF1
2kVbZyicMJD9mG/fxIZDMoQ=
=ZDag
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
lol - Example: I use Eclipse. It's not a "source code editor / syntax
highlighter / code completer", it's a framework that has the JDT - THAT
does those functions. It also doesn't integrate with SVN. Subclipse does
that. So I don't believe Tapestry should do what I'd like - I think
there should be a framework that uses Tapestry for what Tapestry does,
but also has more 'plugins'. If you've ever used Vignette's StoryServer
(or others out there), it's the same concept.
"do it whenever, I don't care"... yeah - never heard that before. :-D
Geoff Longman wrote:
> On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> You know... I think (as much as I'd like to see this just 'built in')
> this is a lot like saying "I'd like my source code editor/syntax
> highlighter/code completer to have source code integration" - it doesn't
> belong. What you need is an "Eclipse/Idea/Pick your IDE" that integrates
> the two.
>
>> The above paragraph is in some English-like language that look
>> *exactly* like English but runs through my brain without computing
>> into anything at all ;-)
>
>> Probably the similar to the language my wife uses to mean "do it
>> yesterday or I will make your life a living hell" when she says "do it
>> whenever, I don't care."
>
>> What does "I'd like my source code editor/syntax
>> highlighter/code completer to have source code integration" mean?
>
>> Geoff
>
>
> Hmmm... Yeah... That would be an interesting endeavor. Time to work out
> something like this... Take that IDE to application-land.
>
> James Carman wrote:
>>>> It might be worth looking into OSCache for this.
>>>>
>>>> -----Original Message-----
>>>> From: Brian K. Wallace [mailto:brian@transmorphix.com]
>>>> Sent: Wednesday, April 26, 2006 2:20 AM
>>>> To: Tapestry development
>>>> Subject: Re: Tapestry 5 progress
>>>>
>>>> Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
>>>> I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
>>>> speed before 5 hits. (feed the masses and all that :-))
>>>>
>>>> In speaking of performance... (I'm off in dream land here, I know... but
>>>> I like it there sometimes)
>>>>
>>>> Many moons ago, there was talk of a 'tool' /'utility' that would
>>>> basically spider a Tapestry app and get all the generated HTML resulting
>>>> in basically a statically generated site. This helps tremendously when
>>>> you're running behind a web server that's tuned to serve static content
>>>> - it's what they do and they do it pretty well with no overhead past
>>>> itself (meaning no java, no db, etc). I'd like to see if we can't add
>>>> some sort of 'cache' attribute to the HTML (somewhere) that would allow
>>>> Tapestry to perform this type of "wait, it says to cache it - i've
>>>> already generated it, I'll just grab that and use it" processing. This
>>>> would also allow Tapestry to build on first access but write out the
>>>> generated HTML so the next time a request comes in for it, the web
>>>> server would find it first (outside the mapping for Tapestry). Granted
>>>> this would only work for pages that were "cache=true" and had no dynamic
>>>> components inside it, but for a lot of sites that's enough (especially
>>>> outside a 'user' area). If there's a static form, submitting it would
>>>> pass back to Tapestry for processing.
>>>>
>>>> I'd see this as only improving performance if you run Tapestry behind
>>>> something like Apache. Granted, you'd get a lot of "that's not fair -
>>>> you're not comparing our framework to yours if you don't hit your
>>>> framework more than once when we have to hit ours every time"
>>>> comments... but hey ;-)
>>>>
>>>> My .02
>>>> Brian
>>>>
>>>> Howard Lewis Ship wrote:
>>>>>> The basic AOP infrastructure is coming along. I expect the rest to
>>>>>> ramp up pretty quickly once I get that in place, but we're still
>>>>>> talking months. Maybe a useable beta by year's end.
>>>>>>
>>>>>> I think I predicted a big performance boost for Tapestry 4 apps vs.
>>>>>> equivalent Tapestry 3 apps. I believe the difference between 4 and 5
>>>>>> will be greater. In fact, I expect OGNL support to be an add on, and
>>>>>> the built-in code will be an improved version of tapestry-prop (from
>>>>>> Tapestry @ JavaForge). I want Tapestry to be extremely high
>>>>>> performance, as one of its differentiators from JSF and Rails.
>>>>>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFET7DVaCoPKRow/gARAmKhAJ9nMufXCvQOfoKYMD1z0rLydvLlSwCfdLF1
2kVbZyicMJD9mG/fxIZDMoQ=
=ZDag
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by Geoff Longman <gl...@gmail.com>.
On 4/26/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> You know... I think (as much as I'd like to see this just 'built in')
> this is a lot like saying "I'd like my source code editor/syntax
> highlighter/code completer to have source code integration" - it doesn't
> belong. What you need is an "Eclipse/Idea/Pick your IDE" that integrates
> the two.
The above paragraph is in some English-like language that look
*exactly* like English but runs through my brain without computing
into anything at all ;-)
Probably the similar to the language my wife uses to mean "do it
yesterday or I will make your life a living hell" when she says "do it
whenever, I don't care."
What does "I'd like my source code editor/syntax
highlighter/code completer to have source code integration" mean?
Geoff
>
> Hmmm... Yeah... That would be an interesting endeavor. Time to work out
> something like this... Take that IDE to application-land.
>
> James Carman wrote:
> > It might be worth looking into OSCache for this.
> >
> > -----Original Message-----
> > From: Brian K. Wallace [mailto:brian@transmorphix.com]
> > Sent: Wednesday, April 26, 2006 2:20 AM
> > To: Tapestry development
> > Subject: Re: Tapestry 5 progress
> >
> > Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
> > I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
> > speed before 5 hits. (feed the masses and all that :-))
> >
> > In speaking of performance... (I'm off in dream land here, I know... but
> > I like it there sometimes)
> >
> > Many moons ago, there was talk of a 'tool' /'utility' that would
> > basically spider a Tapestry app and get all the generated HTML resulting
> > in basically a statically generated site. This helps tremendously when
> > you're running behind a web server that's tuned to serve static content
> > - it's what they do and they do it pretty well with no overhead past
> > itself (meaning no java, no db, etc). I'd like to see if we can't add
> > some sort of 'cache' attribute to the HTML (somewhere) that would allow
> > Tapestry to perform this type of "wait, it says to cache it - i've
> > already generated it, I'll just grab that and use it" processing. This
> > would also allow Tapestry to build on first access but write out the
> > generated HTML so the next time a request comes in for it, the web
> > server would find it first (outside the mapping for Tapestry). Granted
> > this would only work for pages that were "cache=true" and had no dynamic
> > components inside it, but for a lot of sites that's enough (especially
> > outside a 'user' area). If there's a static form, submitting it would
> > pass back to Tapestry for processing.
> >
> > I'd see this as only improving performance if you run Tapestry behind
> > something like Apache. Granted, you'd get a lot of "that's not fair -
> > you're not comparing our framework to yours if you don't hit your
> > framework more than once when we have to hit ours every time"
> > comments... but hey ;-)
> >
> > My .02
> > Brian
> >
> > Howard Lewis Ship wrote:
> >>> The basic AOP infrastructure is coming along. I expect the rest to
> >>> ramp up pretty quickly once I get that in place, but we're still
> >>> talking months. Maybe a useable beta by year's end.
> >>>
> >>> I think I predicted a big performance boost for Tapestry 4 apps vs.
> >>> equivalent Tapestry 3 apps. I believe the difference between 4 and 5
> >>> will be greater. In fact, I expect OGNL support to be an add on, and
> >>> the built-in code will be an improved version of tapestry-prop (from
> >>> Tapestry @ JavaForge). I want Tapestry to be extremely high
> >>> performance, as one of its differentiators from JSF and Rails.
> >>>
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
>
> iD8DBQFET6noaCoPKRow/gARAikKAKDcEAfRIItqd4LgP5DBfqEv+mlgyACgm/Nu
> wL3sefySCxJKT0CsLBeykkI=
> =sF1X
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
The Spindle guy. http://spindle.sf.net
Blog: http://jroller.com/page/glongman
Other interests: http://www.squidoo.com/spaceelevator/
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You know... I think (as much as I'd like to see this just 'built in')
this is a lot like saying "I'd like my source code editor/syntax
highlighter/code completer to have source code integration" - it doesn't
belong. What you need is an "Eclipse/Idea/Pick your IDE" that integrates
the two.
Hmmm... Yeah... That would be an interesting endeavor. Time to work out
something like this... Take that IDE to application-land.
James Carman wrote:
> It might be worth looking into OSCache for this.
>
> -----Original Message-----
> From: Brian K. Wallace [mailto:brian@transmorphix.com]
> Sent: Wednesday, April 26, 2006 2:20 AM
> To: Tapestry development
> Subject: Re: Tapestry 5 progress
>
> Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
> I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
> speed before 5 hits. (feed the masses and all that :-))
>
> In speaking of performance... (I'm off in dream land here, I know... but
> I like it there sometimes)
>
> Many moons ago, there was talk of a 'tool' /'utility' that would
> basically spider a Tapestry app and get all the generated HTML resulting
> in basically a statically generated site. This helps tremendously when
> you're running behind a web server that's tuned to serve static content
> - it's what they do and they do it pretty well with no overhead past
> itself (meaning no java, no db, etc). I'd like to see if we can't add
> some sort of 'cache' attribute to the HTML (somewhere) that would allow
> Tapestry to perform this type of "wait, it says to cache it - i've
> already generated it, I'll just grab that and use it" processing. This
> would also allow Tapestry to build on first access but write out the
> generated HTML so the next time a request comes in for it, the web
> server would find it first (outside the mapping for Tapestry). Granted
> this would only work for pages that were "cache=true" and had no dynamic
> components inside it, but for a lot of sites that's enough (especially
> outside a 'user' area). If there's a static form, submitting it would
> pass back to Tapestry for processing.
>
> I'd see this as only improving performance if you run Tapestry behind
> something like Apache. Granted, you'd get a lot of "that's not fair -
> you're not comparing our framework to yours if you don't hit your
> framework more than once when we have to hit ours every time"
> comments... but hey ;-)
>
> My .02
> Brian
>
> Howard Lewis Ship wrote:
>>> The basic AOP infrastructure is coming along. I expect the rest to
>>> ramp up pretty quickly once I get that in place, but we're still
>>> talking months. Maybe a useable beta by year's end.
>>>
>>> I think I predicted a big performance boost for Tapestry 4 apps vs.
>>> equivalent Tapestry 3 apps. I believe the difference between 4 and 5
>>> will be greater. In fact, I expect OGNL support to be an add on, and
>>> the built-in code will be an improved version of tapestry-prop (from
>>> Tapestry @ JavaForge). I want Tapestry to be extremely high
>>> performance, as one of its differentiators from JSF and Rails.
>>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFET6noaCoPKRow/gARAikKAKDcEAfRIItqd4LgP5DBfqEv+mlgyACgm/Nu
wL3sefySCxJKT0CsLBeykkI=
=sF1X
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: Tapestry 5 progress
Posted by James Carman <ja...@carmanconsulting.com>.
It might be worth looking into OSCache for this.
-----Original Message-----
From: Brian K. Wallace [mailto:brian@transmorphix.com]
Sent: Wednesday, April 26, 2006 2:20 AM
To: Tapestry development
Subject: Re: Tapestry 5 progress
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
speed before 5 hits. (feed the masses and all that :-))
In speaking of performance... (I'm off in dream land here, I know... but
I like it there sometimes)
Many moons ago, there was talk of a 'tool' /'utility' that would
basically spider a Tapestry app and get all the generated HTML resulting
in basically a statically generated site. This helps tremendously when
you're running behind a web server that's tuned to serve static content
- - it's what they do and they do it pretty well with no overhead past
itself (meaning no java, no db, etc). I'd like to see if we can't add
some sort of 'cache' attribute to the HTML (somewhere) that would allow
Tapestry to perform this type of "wait, it says to cache it - i've
already generated it, I'll just grab that and use it" processing. This
would also allow Tapestry to build on first access but write out the
generated HTML so the next time a request comes in for it, the web
server would find it first (outside the mapping for Tapestry). Granted
this would only work for pages that were "cache=true" and had no dynamic
components inside it, but for a lot of sites that's enough (especially
outside a 'user' area). If there's a static form, submitting it would
pass back to Tapestry for processing.
I'd see this as only improving performance if you run Tapestry behind
something like Apache. Granted, you'd get a lot of "that's not fair -
you're not comparing our framework to yours if you don't hit your
framework more than once when we have to hit ours every time"
comments... but hey ;-)
My .02
Brian
Howard Lewis Ship wrote:
> The basic AOP infrastructure is coming along. I expect the rest to
> ramp up pretty quickly once I get that in place, but we're still
> talking months. Maybe a useable beta by year's end.
>
> I think I predicted a big performance boost for Tapestry 4 apps vs.
> equivalent Tapestry 3 apps. I believe the difference between 4 and 5
> will be greater. In fact, I expect OGNL support to be an add on, and
> the built-in code will be an improved version of tapestry-prop (from
> Tapestry @ JavaForge). I want Tapestry to be extremely high
> performance, as one of its differentiators from JSF and Rails.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFETw8naCoPKRow/gARAvd+AKCDU/DGNTKXPfhaJyb+5oNlMT0S1wCcC4ZE
stsYXpMZrbap+Q7Jxn+Lh0k=
=xbzo
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Works for me. Plenty of growing room for 4 left anyway, right Jesse? ;-)
I'm just hoping to get documentation (*ugh*) and tooling (Spindle) up to
speed before 5 hits. (feed the masses and all that :-))
In speaking of performance... (I'm off in dream land here, I know... but
I like it there sometimes)
Many moons ago, there was talk of a 'tool' /'utility' that would
basically spider a Tapestry app and get all the generated HTML resulting
in basically a statically generated site. This helps tremendously when
you're running behind a web server that's tuned to serve static content
- - it's what they do and they do it pretty well with no overhead past
itself (meaning no java, no db, etc). I'd like to see if we can't add
some sort of 'cache' attribute to the HTML (somewhere) that would allow
Tapestry to perform this type of "wait, it says to cache it - i've
already generated it, I'll just grab that and use it" processing. This
would also allow Tapestry to build on first access but write out the
generated HTML so the next time a request comes in for it, the web
server would find it first (outside the mapping for Tapestry). Granted
this would only work for pages that were "cache=true" and had no dynamic
components inside it, but for a lot of sites that's enough (especially
outside a 'user' area). If there's a static form, submitting it would
pass back to Tapestry for processing.
I'd see this as only improving performance if you run Tapestry behind
something like Apache. Granted, you'd get a lot of "that's not fair -
you're not comparing our framework to yours if you don't hit your
framework more than once when we have to hit ours every time"
comments... but hey ;-)
My .02
Brian
Howard Lewis Ship wrote:
> The basic AOP infrastructure is coming along. I expect the rest to
> ramp up pretty quickly once I get that in place, but we're still
> talking months. Maybe a useable beta by year's end.
>
> I think I predicted a big performance boost for Tapestry 4 apps vs.
> equivalent Tapestry 3 apps. I believe the difference between 4 and 5
> will be greater. In fact, I expect OGNL support to be an add on, and
> the built-in code will be an improved version of tapestry-prop (from
> Tapestry @ JavaForge). I want Tapestry to be extremely high
> performance, as one of its differentiators from JSF and Rails.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFETw8naCoPKRow/gARAvd+AKCDU/DGNTKXPfhaJyb+5oNlMT0S1wCcC4ZE
stsYXpMZrbap+Q7Jxn+Lh0k=
=xbzo
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by Howard Lewis Ship <hl...@gmail.com>.
The basic AOP infrastructure is coming along. I expect the rest to
ramp up pretty quickly once I get that in place, but we're still
talking months. Maybe a useable beta by year's end.
I think I predicted a big performance boost for Tapestry 4 apps vs.
equivalent Tapestry 3 apps. I believe the difference between 4 and 5
will be greater. In fact, I expect OGNL support to be an add on, and
the built-in code will be an improved version of tapestry-prop (from
Tapestry @ JavaForge). I want Tapestry to be extremely high
performance, as one of its differentiators from JSF and Rails.
On 4/25/06, Brian K. Wallace <br...@transmorphix.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> First off - this is great news (IMO). It's great to see a new look as
> it's being checked in.
>
> The following is nothing short of my own idle curiosity: when do you /
> would you envision 5 rolling out? [no jumping down the new guy's throat
> - - I'm just curious. I know there's a lot left before anything thrown out
> would be anything more than conjecture/hope] I'm really looking forward
> to seeing the two sides (Howard's / Jesse's) meeting and pushing
> Tapestry that much farther.
>
> Howard Lewis Ship wrote:
> > I'm having a lot of fun with the tapestry5 code.
> >
> > Back in January 2000, I spent almost two weeks getting Tapestry from
> > an idea to a lame "Hello World". I had to do lots of work and learn
> > many things, including the SAX API, designing and implementing the
> > component specification hierarchy, designing and implementing the
> > component structure, all the reflective instantiation, the initial
> > primitive template parser, and so forth.
> >
> > I think that time was well spent, it "injected energy" into Tapestry
> > that served it well for several years, giving it a powerful core that
> > was quite amenable to change and improvement.
> >
> > I'm putting much more effort into the new code base, along with six
> > years of accumulated experience. It feels like I'm winding it up like
> > a spring (no pun intended). It's exhilarating.
> >
> > Right now, what I'm building looks more like an AOP system than a web
> > framework ... that'll come later. I need to catch up on Jesse's work
> > on the JSOnRenderer since those ideas should be folded in and
> > improved.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
>
> iD8DBQFETwNAaCoPKRow/gARAlfxAKCOquc4t/i/2XbEqBEd+NMDNU8eBgCg2gkd
> GC8fEpi5KxHSfi8xSvXQHsA=
> =9v6P
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
--
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: Tapestry 5 progress
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
First off - this is great news (IMO). It's great to see a new look as
it's being checked in.
The following is nothing short of my own idle curiosity: when do you /
would you envision 5 rolling out? [no jumping down the new guy's throat
- - I'm just curious. I know there's a lot left before anything thrown out
would be anything more than conjecture/hope] I'm really looking forward
to seeing the two sides (Howard's / Jesse's) meeting and pushing
Tapestry that much farther.
Howard Lewis Ship wrote:
> I'm having a lot of fun with the tapestry5 code.
>
> Back in January 2000, I spent almost two weeks getting Tapestry from
> an idea to a lame "Hello World". I had to do lots of work and learn
> many things, including the SAX API, designing and implementing the
> component specification hierarchy, designing and implementing the
> component structure, all the reflective instantiation, the initial
> primitive template parser, and so forth.
>
> I think that time was well spent, it "injected energy" into Tapestry
> that served it well for several years, giving it a powerful core that
> was quite amenable to change and improvement.
>
> I'm putting much more effort into the new code base, along with six
> years of accumulated experience. It feels like I'm winding it up like
> a spring (no pun intended). It's exhilarating.
>
> Right now, what I'm building looks more like an AOP system than a web
> framework ... that'll come later. I need to catch up on Jesse's work
> on the JSOnRenderer since those ideas should be folded in and
> improved.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFETwNAaCoPKRow/gARAlfxAKCOquc4t/i/2XbEqBEd+NMDNU8eBgCg2gkd
GC8fEpi5KxHSfi8xSvXQHsA=
=9v6P
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Tapestry 5 progress
Posted by Jesse Kuhnert <jk...@gmail.com>.
Yeah, I think what you are doing is pretty awesome :) Hopefully I'll have a
lot more of the JSON / ajax rendering cycle stuff done once I get back from
this gig. (I plan on really focusing on this only now besides $$ work).
It looks really exciting. You are going to make the other frameworks look
like such a joke now comparatively. It almost doesn't seem fair ;) This is
definitely "the one" in my eyes. Doesn't get much better.
On 4/25/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> I'm having a lot of fun with the tapestry5 code.
>
> Back in January 2000, I spent almost two weeks getting Tapestry from
> an idea to a lame "Hello World". I had to do lots of work and learn
> many things, including the SAX API, designing and implementing the
> component specification hierarchy, designing and implementing the
> component structure, all the reflective instantiation, the initial
> primitive template parser, and so forth.
>
> I think that time was well spent, it "injected energy" into Tapestry
> that served it well for several years, giving it a powerful core that
> was quite amenable to change and improvement.
>
> I'm putting much more effort into the new code base, along with six
> years of accumulated experience. It feels like I'm winding it up like
> a spring (no pun intended). It's exhilarating.
>
> Right now, what I'm building looks more like an AOP system than a web
> framework ... that'll come later. I need to catch up on Jesse's work
> on the JSOnRenderer since those ideas should be folded in and
> improved.
>
>
> On 4/25/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> > I'm green with envy! I knew starting more of that autocompleter support
> > would only make me depressed because I'd have to leave it before I was
> > finished for this traveling work I'm in the middle of this week.
> >
> > I'll see if I can catch up in pulling my coding weight when I get back.
> Nice
> > to see so much work going on. You must be having a lot of fun being able
> to
> > design around these concepts :(
> >
> > On 4/24/06, hlship@apache.org <hl...@apache.org> wrote:
> > >
> > > Author: hlship
> > > Date: Mon Apr 24 17:52:01 2006
> > > New Revision: 396751
> > >
> > > URL: http://svn.apache.org/viewcvs?rev=396751&view=rev
> > > Log:
> > > Make ComponentLifecycle extend from ResourceAware.
> > > Move core initialization logic (i.e., components implement
> > > ComponentLifecycle) into InternalComponentTransformationImpl.
> > > Remove the readMeta() and writeMeta() methods from
> ComponentTransformation
> > > Add getResourcesFieldName() method to ComponentTransformation
> > > Modify the ComponentTransformation to be frozen after invoking
> finish()
> > >
> > > Removed:
> > >
> > >
> tapestry/tapestry5/tapestry-core/trunk/src/main/java/org/apache/tapestry/internal/transform/worker/ImplementResourceAwareWorker.java
> > >
> > >
> tapestry/tapestry5/tapestry-core/trunk/src/test/java/org/apache/tapestry/internal/transform/worker/ImplementResourceAwareWorkerTest.java
> > > Modified:
> > > tapestry/tapestry5/tapestry-core/trunk/src/main/java/org
> >
> >
> >
> >
> > --
> > Jesse Kuhnert
> > Tacos/Tapestry, team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind.
> >
> >
>
>
> --
> 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
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.