Hi John, There is no single formula, it just depends on the way you like to work.. Tapestry does make things easy though because by nature its very modular, and IoC by nature encourages better interoperability. We currently have about 7 Tapestry applications sharing resources, so here are some very basic tips:
> 1. Seems like the best unit of sharing would be at the component level. Am I > missing anything else? Separate your code, all of it... layer it correctly and it will reward you later, another rule of thumb is to ensure its testable > 2. How to best manage the shared components and dependencies between teams? Personally I don't like mixing state or database access within components, I like my components purely mechanical, but most of all encapsulated, i,.e.: maximize reuse keeping them generic, that way they almost evolve on their own into a library. I use IoC for database access and business logic, I also use the occasional base page to simplify pages. > 3. What CSS and HTML conventions would be needed for this to work? > (object-oriented CSS?) Pardon me for saying so but CSS and object-oriented are just not compatible concepts, perhaps you meant inheritance? CSS is such a simple concept with very simple rules, so its surprising that it can be very tricky to get it right... Many developers are naive thinking its a breeze and tend to dive in with reckless abandon, then later down the line wake up to a complete mess, oblivious to this fact that even CSS needs thought. The real world 'standard' implementation is hardly that, and inheritance structure of CSS is a not far short of a disaster, like a house of cards, especially if used badly. Mastery of CSS takes a bit of time and experience, again not everyone will agree on how to use it best, so do your research and find what works for you. General rules that work well for me is to avoid globals wherever possible, and you would be surprised how little you actually need them. I use a reset style sheet to begin with a clean cross-browser slate, I use master style sheet to to source in other style sheets (this way I can separate style sheets conceptually, i.e.: layout vs typography etc.) I keep these style sheets very minimal because bear in mind they are dragged around everywhere. When I develop components I generally include a component specific style sheet, but limit styles to a functional few, leaving the application specific appearance to the container styles. I want my components to be completely encapsulated and transferable when used in other applications, without breaking the UI or CSS, and its easy with Tapestry > 4. Are there any tools to help ensure best practices are being followed? I don't know of any... does a tool make sense? perhaps! >5. How does having a large number of components affect performance? (should >we have lots of small components, or less number of larger components…does it >make a difference?) Performance will not be an issue, maintenance may be though, design with maintenance in mind. Mixins are a huge boon here, they are a great way to extend a components functionality, and to clean up duplicated and unmaintainable JavaScript. My 2 cents, Peter ----- Original Message ----- From: "John York" <john.y...@proquest.com> To: users@tapestry.apache.org Sent: Monday, 18 April, 2011 23:09:24 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Managing a large multi-team project with Tapestry 5 Hi all, my organization recently released a large project using Tapestry 5. We are in the process of starting another large project and are hoping to leverage some of the existing Tapestry work and components that have already been implemented. We plan to form a second team and would like that team to work in parallel with the existing team. I am new to Tapestry and I'm concerned about a number of things: 1. Seems like the best unit of sharing would be at the component level. Am I missing anything else? 2. How to best manage the shared components and dependencies between teams? 3. What CSS and HTML conventions would be needed for this to work? (object-oriented CSS?) 4. Are there any tools to help ensure best practices are being followed? 5. How does having a large number of components affect performance? (should we have lots of small components, or less number of larger components…does it make a difference?) I appreciate any feedback. Thanks, John York --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
