Hi, We have 4 teams of 6-8 people each working on a pretty large Tapestry project. We've encountered quite a few of these problems along the way ;) I have to agree with Peter, well separated, testable code will make your life immeasurably easier - get this bit right and everything else should flow out of it.
Don't underestimate the importance of education. In my experience not many new hires have exposure to T5 or any other component based framework, they think in actions. You need to make sure the whole team understands components, their benefits and how to use/create/maintain them. In terms of tools, you can use things like PMD, Checkstyle and Cobertura to fail the build if coding or coverage standards are violated. We've found this helps to keep the code consistent from one person to the next, but it can still let through anti-patterns because the focus is at the lower level. Recently we've been looking at Fisheye and Crucible from Atlassian. These provide repo browsing and collaborative code review. They are a good suite and allow for web-based, async code review when we've found is easier to manage than getting whole teams in a room to pour over chunks of code. Good luck! Toby. On 19/04/2011 08:57, "p.stavrini...@albourne.com" <p.stavrini...@albourne.com> wrote: >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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
