> > Why can't we already do that with a Layout component, CSS and the > Delegate component?
Skinning means you drop in a skin to some folder and everything changes automatically. With the layout component you have to manually adjust it. Core support means, that there is a core mechanism to find skins automatically and be able to change the looks at runtime for example with a listbox "Skinchanger". If I drop in new classes into a running app the class reloading doesn't take them up. Only changed classes which were there at startup. Skinning support would also require that all the css, js and whatever else you need is preferably in one place. The point with that is, that if I write for example a blog module it should seamlessly integrate into the looks of the site. At the moment it is a bit awkward. The new archetype look is really nice - until you use tapestry core components like the grid. The blue and the beige/brown really bite each other. And though it is possible to pull the grid css from the classpath and override the classes you want, that is imho a really less than optimal solution. A centralized skinning facility would ease that process a lot. > > core ability to draw templates from > > arbitrary locations > > Some people in this list have already done that. > Yes, some did it. IIRC they had to override core classes /services for that. I'm uneasy about that, especially when thinking about the fact that Tap5.1 is _mostly_ backwards compatible, but not _fully_. These things are needed or would at least be warmly greeted in about every contemporary webapp. Having to maintain overrides which possibly use internal services and classes with each version change is an unneccesary strain, I think. This will eventually happen as time passes. Tapestry 5 is still a > young framework. Yes of course. Thatswhy I don't think it will happen soon :) > > If you build high level components on the raw framework you'll run into > > compatibility and interoperability issues otherwise. > > I'm not following you. Please enlighten me on what these compatibility > and interoperability are. :) > Let's say I write a forum module. This needs access restrictions and a hierarchy of user rights. If I dice my own for this component this would mean that you have possibly 2 (or even more with other components which also dice their own user-management) authentication mechanisms. With a standard auth-service with accompanying components for login, access restrictions etc. I could just rely on that. That would also give clear extension points where professionals with non-standard needs for authentication, could customize by implementing the standard security service/components' interface. > Grails' success comes mostly from the rich ecosystem of plugins (and Gorm) > > which _mostly_ interoperate just fine. To achieve the same in Tapestry is > > not possible in the way they do it there, > > Why not? Because nobody would want to write the build system and also quite some of the magic comes from groovys dynamic nature and especially gorm. And though it is possible to use Gorm with Tapestry, you are forced then to write all classes which use its dynamic finders for example in groovy. If you factor data access code out into daos or services you don't have a real advantage over plain old hibernate and writing all services, pages and components in groovy... well then you can use grails with all its plugins straight away since you loose the advantage of statically typed Java anyways. > but it should be possible to come > > near enough when there are some well defined interfaces where you can > plug > > in your components. > > I guess you mean services instead of components in this message, > something that confuses your reasoning. Yes there is some confusion, sorry for that. I tried to stick more to the correct terms this time.
