EditObject component (was: Re: new blood)

[Chris Nelson <cn...@yahoo.com>]

There is already a trails:ObjectForm component that is
not tied to Spring or Hibernate.  It gets passed a
Descriptor object as a parameter which represents
information about a POJO.  

How about we avoid writing this yet again... ;)

--- "Brian K. Wallace" <br...@transmorphix.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Leonardo Quijano Vincenzi wrote:
> > Jesse, those where 3 ideas, not 2 :P.
> > But anyway...
> > 
> > 1) As far as I understood, this translator stuff
> is to make Tapestry
> > more autobinding capable. Since most of my forms
> deal with "foo.bar"
> > expressions (some object and a property inside of
> that object), as long
> > as autowiring supports that, I'm happy.
> > 2) This is for the performance concerned guys ;).
> Needed, though.
> > 
> > 3)
> >
> Yet-another-Hibernate-Tapestry-Integration-Project?
> Really, why don't
> > people just use Spring? Unless someone comes up
> with a Seam equivalent
> > for Tapestry, I don't understand exactly what's
> the purpose of this.
> > 
> > That said, I do have some
> Hibernate-Spring-Tapestry stuff I could
> > eventually contribute, dealing with long sessions
> (which are needed for
> > *everything* in Hibernate.... what a waste of
> resources..).
> > 
> > My 2 desired things:
> > 4) A janitorial project / section / component /
> whatever. Yeah, I know
> > it's not as sexy. But really... it's needed.
> It's the "what's needed" from a user's point of view
> that interests me.
> I don't need pretty. I just need fewer questions to
> be answered. :-)
> (not that I don't want pretty, just that Tapestry
> already does so much
> that either a) isn't quite there for "less than
> edge" cases or b) isn't
> documented - or not as easy to find. [more an
> agreement on #4 than a
> documentation push there :-)]
> 
> > 5) DHTML subproject... not only Ajax but also
> simpler effects, including
> > validation, enabling / disabling components, etc..
> I wrote about this
> > some time ago.
> > 
> > In any case, I'm getting worried that the focus is
> losing in this
> > development. I wonder, why don't we focus all
> resources into removing
> > the rewind cycle, or eliminating abstract classes,
> or some of the other
> > stuff Howard said he would like for Tap 4.1 / 5 ?
> There are quite a few things that were talked about
> - first for 3.1/4.0,
> now 4.1/5.0 that get left behind with evolution. I'd
> like to propose
> (yeah, I did this before :-)) a roadmap with issues
> assigned to achieve
> the goals set out in it. There will be bugs, but for
> X.0/X.1/X.2/etc
> releases there should be some sort of "written in
> jello" features. If it
> takes brain dumping all itemized features, then
> splitting them off into
> releases, maybe we can continue to get those done
> while new things are
> being dreamed up.
> > 
> > Or else we'll end up with a 3 year development
> cycle...
> > 
> NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
> 
>
iD8DBQFEMslhaCoPKRow/gARAnOaAKDQGmxNcs5oQ51iphMEpkR95slD7wCeNDSc
> 9iUG/2hwTpgMBLm1erE+Y64=
> =g+Ua
> -----END PGP SIGNATURE-----
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-dev-help@jakarta.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: EditObject component (was: Re: new blood)

[Chris Nelson <cn...@yahoo.com>]

I misspoke, it does use Spring but not Hibernate.  It
uses a subcomponent, EditProperties, which gets
injected with BlockFinder spring bean.  There is no
reason this couldn't be moved into Hivemind tho, if
that makes it more palatable to the Tapestry
community.  

The BlockFinder grabs finds the right block for each
type of property, so these blocks would contain
components(TextField, DatePicker, etc) which would
have translators and validators.

--- Jesse Kuhnert <jk...@gmail.com> wrote:

> Really? Does it do what is described on Howard's
> blog as well? (ie tying in
> to the validation system to do auto validating
> things on object types where
> it makes sense? )
> 
> I'm all for not repeating things, if trails has the
> ability to do this, and
> is also fairly easy to just plug in then maybe we
> need to think about
> promoting trails more. I had thought that there were
> some issues with heavy
> handed installation requirements for the project,
> but perhaps this
> trails:ObjectForm is a different story.
> 
> I just really want to figure out what the best
> implementation we have going
> for us so far is and then make sure we support and
> promote it's continued
> development.
> 
> On 4/4/06, Chris Nelson <cn...@yahoo.com>
> wrote:
> >
> > There is already a trails:ObjectForm component
> that is
> > not tied to Spring or Hibernate.  It gets passed a
> > Descriptor object as a parameter which represents
> > information about a POJO.
> >
> > How about we avoid writing this yet again... ;)
> >
> > --- "Brian K. Wallace" <br...@transmorphix.com>
> wrote:
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Leonardo Quijano Vincenzi wrote:
> > > > Jesse, those where 3 ideas, not 2 :P.
> > > > But anyway...
> > > >
> > > > 1) As far as I understood, this translator
> stuff
> > > is to make Tapestry
> > > > more autobinding capable. Since most of my
> forms
> > > deal with "foo.bar"
> > > > expressions (some object and a property inside
> of
> > > that object), as long
> > > > as autowiring supports that, I'm happy.
> > > > 2) This is for the performance concerned guys
> ;).
> > > Needed, though.
> > > >
> > > > 3)
> > > >
> > >
> Yet-another-Hibernate-Tapestry-Integration-Project?
> > > Really, why don't
> > > > people just use Spring? Unless someone comes
> up
> > > with a Seam equivalent
> > > > for Tapestry, I don't understand exactly
> what's
> > > the purpose of this.
> > > >
> > > > That said, I do have some
> > > Hibernate-Spring-Tapestry stuff I could
> > > > eventually contribute, dealing with long
> sessions
> > > (which are needed for
> > > > *everything* in Hibernate.... what a waste of
> > > resources..).
> > > >
> > > > My 2 desired things:
> > > > 4) A janitorial project / section / component
> /
> > > whatever. Yeah, I know
> > > > it's not as sexy. But really... it's needed.
> > > It's the "what's needed" from a user's point of
> view
> > > that interests me.
> > > I don't need pretty. I just need fewer questions
> to
> > > be answered. :-)
> > > (not that I don't want pretty, just that
> Tapestry
> > > already does so much
> > > that either a) isn't quite there for "less than
> > > edge" cases or b) isn't
> > > documented - or not as easy to find. [more an
> > > agreement on #4 than a
> > > documentation push there :-)]
> > >
> > > > 5) DHTML subproject... not only Ajax but also
> > > simpler effects, including
> > > > validation, enabling / disabling components,
> etc..
> > > I wrote about this
> > > > some time ago.
> > > >
> > > > In any case, I'm getting worried that the
> focus is
> > > losing in this
> > > > development. I wonder, why don't we focus all
> > > resources into removing
> > > > the rewind cycle, or eliminating abstract
> classes,
> > > or some of the other
> > > > stuff Howard said he would like for Tap 4.1 /
> 5 ?
> > > There are quite a few things that were talked
> about
> > > - first for 3.1/4.0,
> > > now 4.1/5.0 that get left behind with evolution.
> I'd
> > > like to propose
> > > (yeah, I did this before :-)) a roadmap with
> issues
> > > assigned to achieve
> > > the goals set out in it. There will be bugs, but
> for
> > > X.0/X.1/X.2/etc
> > > releases there should be some sort of "written
> in
> > > jello" features. If it
> > > takes brain dumping all itemized features, then
> > > splitting them off into
> > > releases, maybe we can continue to get those
> done
> > > while new things are
> > > being dreamed up.
> > > >
> > > > Or else we'll end up with a 3 year development
> > > cycle...
> > > >
> > > NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.2.5 (MingW32)
> > >
> > >
> >
>
iD8DBQFEMslhaCoPKRow/gARAnOaAKDQGmxNcs5oQ51iphMEpkR95slD7wCeNDSc
> > > 9iUG/2hwTpgMBLm1erE+Y64=
> > > =g+Ua
> > > -----END PGP SIGNATURE-----
> > >
> > >
> >
>
---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > tapestry-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.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.  http://opennotion.com
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: EditObject component (was: Re: new blood)

[Jesse Kuhnert <jk...@gmail.com>]

Really? Does it do what is described on Howard's blog as well? (ie tying in
to the validation system to do auto validating things on object types where
it makes sense? )

I'm all for not repeating things, if trails has the ability to do this, and
is also fairly easy to just plug in then maybe we need to think about
promoting trails more. I had thought that there were some issues with heavy
handed installation requirements for the project, but perhaps this
trails:ObjectForm is a different story.

I just really want to figure out what the best implementation we have going
for us so far is and then make sure we support and promote it's continued
development.

On 4/4/06, Chris Nelson <cn...@yahoo.com> wrote:
>
> There is already a trails:ObjectForm component that is
> not tied to Spring or Hibernate.  It gets passed a
> Descriptor object as a parameter which represents
> information about a POJO.
>
> How about we avoid writing this yet again... ;)
>
> --- "Brian K. Wallace" <br...@transmorphix.com> wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Leonardo Quijano Vincenzi wrote:
> > > Jesse, those where 3 ideas, not 2 :P.
> > > But anyway...
> > >
> > > 1) As far as I understood, this translator stuff
> > is to make Tapestry
> > > more autobinding capable. Since most of my forms
> > deal with "foo.bar"
> > > expressions (some object and a property inside of
> > that object), as long
> > > as autowiring supports that, I'm happy.
> > > 2) This is for the performance concerned guys ;).
> > Needed, though.
> > >
> > > 3)
> > >
> > Yet-another-Hibernate-Tapestry-Integration-Project?
> > Really, why don't
> > > people just use Spring? Unless someone comes up
> > with a Seam equivalent
> > > for Tapestry, I don't understand exactly what's
> > the purpose of this.
> > >
> > > That said, I do have some
> > Hibernate-Spring-Tapestry stuff I could
> > > eventually contribute, dealing with long sessions
> > (which are needed for
> > > *everything* in Hibernate.... what a waste of
> > resources..).
> > >
> > > My 2 desired things:
> > > 4) A janitorial project / section / component /
> > whatever. Yeah, I know
> > > it's not as sexy. But really... it's needed.
> > It's the "what's needed" from a user's point of view
> > that interests me.
> > I don't need pretty. I just need fewer questions to
> > be answered. :-)
> > (not that I don't want pretty, just that Tapestry
> > already does so much
> > that either a) isn't quite there for "less than
> > edge" cases or b) isn't
> > documented - or not as easy to find. [more an
> > agreement on #4 than a
> > documentation push there :-)]
> >
> > > 5) DHTML subproject... not only Ajax but also
> > simpler effects, including
> > > validation, enabling / disabling components, etc..
> > I wrote about this
> > > some time ago.
> > >
> > > In any case, I'm getting worried that the focus is
> > losing in this
> > > development. I wonder, why don't we focus all
> > resources into removing
> > > the rewind cycle, or eliminating abstract classes,
> > or some of the other
> > > stuff Howard said he would like for Tap 4.1 / 5 ?
> > There are quite a few things that were talked about
> > - first for 3.1/4.0,
> > now 4.1/5.0 that get left behind with evolution. I'd
> > like to propose
> > (yeah, I did this before :-)) a roadmap with issues
> > assigned to achieve
> > the goals set out in it. There will be bugs, but for
> > X.0/X.1/X.2/etc
> > releases there should be some sort of "written in
> > jello" features. If it
> > takes brain dumping all itemized features, then
> > splitting them off into
> > releases, maybe we can continue to get those done
> > while new things are
> > being dreamed up.
> > >
> > > Or else we'll end up with a 3 year development
> > cycle...
> > >
> > NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.5 (MingW32)
> >
> >
> iD8DBQFEMslhaCoPKRow/gARAnOaAKDQGmxNcs5oQ51iphMEpkR95slD7wCeNDSc
> > 9iUG/2hwTpgMBLm1erE+Y64=
> > =g+Ua
> > -----END PGP SIGNATURE-----
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.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.  http://opennotion.com