I'm not putting down HM in any way. It is the *enabler* and the *glue* in T4 today. I see resistance here at work to Tapestry 4 and a lot of it has to do with being forced to learn HM to do what appear to be mundane tasks.
One example is Services. They were very simple to create and add to an app pre T4. No so easy now. Are they more powerful now? Absolutely. Could a convention and a little more (ok maybe a lot more) work behind the scenes let us bring back the <service> tag and cover a large percentage of user's needs? I think so. HM operates behind the scenes always as the enabler of the convention and the full power of HM is always available for those crazy corner cases. Our app is currently built around Spring. I know we can reuse that stuff in T4 which is excellent. If we have a working app in T3 that has over 100 Spring managed beans and services so we are not going to change any that stuff over to HM managed entities. So, the less we need to care about HM the better for us. We add a new developer about every month and the learning curve is steep already. Ideally, we would rather not have to pile on HM up front, HM use should be needed in only the exceptional cases where a few incumbents can handle it and the new guy can pick it up later as needed. To me it's like having Excel mandate that the sorting of data be done using a VB script authored by the user. In Excel they have a menu item to sort and can use VB for the exceptional cases. In Tapestry conventions are the menu item and HM is the super powerful tool you look to solve that really complex problem. 90% of Excel uses never write a script. If even 80-90% of the time users could rely on a convention over a HM contribution I think that would be a big plus for adoption. Not a rant this time. just my opinion. Geoff On 6/15/06, James Carman <[EMAIL PROTECTED]> wrote:
That would work, too. But, HiveMind already has the auto-discovery stuff built in. It's really not that hard to configure stuff via HiveMind. Of course, that's coming from a HiveMind committer. :-) -----Original Message----- From: Geoff Longman [mailto:[EMAIL PROTECTED] Sent: Thursday, June 15, 2006 2:31 PM To: Tapestry users Subject: Re: custom namespace You run the risk of me going into the whole sob story about T4 and how to fix it in T5! :-) Why isn't the .library file enough config? Just put it in the META-INF dir of the jar and have Tapestry autodiscover it. ? Geoff On 6/15/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > In the context of that suggestion, where would you see this configuration > data going ? > > On 6/15/06, Geoff Longman <[EMAIL PROTECTED]> 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] > > > > > > > > > > > > -- > > The Spindle guy. http://spindle.sf.net > > Blog: http://jroller.com/page/glongman > > Other interests: http://www.squidoo.com/spaceelevator/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. > > -- The Spindle guy. http://spindle.sf.net Blog: http://jroller.com/page/glongman Other interests: http://www.squidoo.com/spaceelevator/ --------------------------------------------------------------------- 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]
-- The Spindle guy. http://spindle.sf.net Blog: http://jroller.com/page/glongman Other interests: http://www.squidoo.com/spaceelevator/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
