There's a new enhancement that allows you to create a base class and have your HM services auto-wired in. It's available in 4.1.
-----Original Message----- From: Gentry, Michael (Contractor) [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 11:41 AM To: Tapestry users Subject: RE: custom namespace +1 (to Bryan and Geoff). I'm still mumbling over getVisit() (as an example) being deprecated. Something as simple as getting your session in a session-based application shouldn't require HM (or Annotations, which don't work in Java 1.4.x, or XML for N pages to do an inject of the HM class (oh, and <inject> doesn't inherit, so forget about a simple base class to put it in)). The OOP approach was Just Fine as far as I'm concerned. The T3->T4 upgrade was fairly rough for me, and my applications are pretty small. Lots of things changed and the docs, which I understand are difficult to write, didn't provide enough useful information. Tapestry already had a big enough learning curve, and then some of the simple things became difficult all in the name of flexibility. Thanks, /dev/mrg -----Original Message----- From: Bryan Lewis [mailto:[EMAIL PROTECTED] Sent: Thursday, June 15, 2006 11:03 PM To: Tapestry users Subject: Re: custom namespace Dunno about that. I haven't tried Rails and am not familiar with the implications of COP. I was agreeing with the sentiment against using HiveMind for everyday things. I had a perfectly good set of applications running in Tapestry3 last year and thought I was one of those lucky developers that didn't feel much pain from the learning curve. But upgrading to Tap4 felt like a bigger jump. Can't say exactly why but HiveMind usually seemed to be involved when I got stumped. My apps are back to fast and stable again, and I agree that some things are cleaner now, the naming is more consistent and some more plumbing code went away, but it took me a long time and a lot of following this list. I don't mean to sound luddite, just reporting my experience. Whenever I see a recommendation to use HiveMind to do some little thing that was only a matter of OOP before, I feel the way Geoff expressed. James Carman wrote: >So, you want Tapestry to switch to convention-oriented programming (a la >Rails)? > > >-----Original Message----- >From: Bryan Lewis [mailto:[EMAIL PROTECTED] >Sent: Thursday, June 15, 2006 3:20 PM >To: Tapestry users >Subject: Re: custom namespace > >+1 for that rant. > > >Geoff Longman wrote: > > > >>Good God No! >> >>While I love the idea of auto discovery of libraries, every time I see >>a quick suggestion to use Hivemind I cringe. >> >>IMO HM is *required* to do too many everyday things in T4. HM should >>be relegated to use when the *implementation of the runtime* needs to >>be changed or enhanced because a convention doesn't handle a >>particular case. A normal everyday user should be able to build >>libraries, have full featured ASO's, and build services without ever >>writing a line of HM config. >> >>That puts a lot more pressure on the committers to identify the >>everyday tasks and find intelligent conventions for users to do >>something without writing HM code. That doesn't mean HM is out of the >>mix, it's just out of sight and available for those 1% cases where you >>just have to make Tap behave differently from the convention. Really, >>in a perfect world the Tapestry docs would make no reference to HM >>except in an appendix. >> >>end of rant! >> >>Geoff >> >>On 6/15/06, James Carman <[EMAIL PROTECTED]> wrote: >> >> >> >>>It would be nice if the component libraries could add themselves to >>>the mix >>>via a HiveMind contribution. Of course, they would allow "users" to >>>override their default namespace via a symbol override contribution or >>>something. That's the way I'd do it. >>> >>>-----Original Message----- >>>From: Norbert Sándor [mailto:[EMAIL PROTECTED] >>>Sent: Thursday, June 15, 2006 12:27 PM >>>To: Tapestry users >>>Subject: Re: custom namespace >>> >>>I use many such component libraries which means that because of this >>>issue, many libraries must be specified "by hand". >>>Not a big problem, just tried to avoid it :) >>> >>>Regards, >>>Norbi >>> >>>Geoff Longman wrote: >>> >>> >>>>Yes, that's true. But is that really a problem? Contrib has the same >>>>issue. >>>> >>>>Geoff >>>> >>>>On 6/15/06, Norbert Sándor <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>>>Thanks! >>>>> >>>>>This means that I must force the user of my component library to >>>>> >>>>> >>>define >>> >>> >>>>>my library with a fix alias in the .application file. >>>>> >>>>>Regards, >>>>>Norbi >>>>> >>>>>Jesse Kuhnert wrote: >>>>> >>>>> >>>>>>You mean like contrib or tacos? I think the namespace name can >>>>>> >>>>>> >>>be tied >>> >>> >>>>>>to a >>>>>>.library file via your .application configuration. (this I'm >>>>>> >>>>>> >>>less sure >>> >>> >>>>>>of as >>>>>>the best solution) >>>>>> >>>>>>On 6/14/06, Norbert Sándor <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> >>>>>>>Hi, >>>>>>> >>>>>>>By default there are 2 namespaces: framework and application. >>>>>>>How can I define my own, custom namespace? >>>>>>> >>>>>>>Regards, >>>>>>>Norbi >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>--------------------------------------------------------------------- >>> >>> >>>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>>For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>------------------------------------------------------------------------ >>> >>> >>>>>>No virus found in this incoming message. >>>>>>Checked by AVG Free Edition. >>>>>>Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: >>>>>> >>>>>> >>>>>2006.06.12. >>>>> >>>>> >>>>>--------------------------------------------------------------------- >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> >> >> > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
