On Thu, Jul 23, 2009 at 10:34 AM, Jeff Hammel<[email protected]> wrote: > > On Thu, Jul 23, 2009 at 10:32:14AM -0500, Olemis Lang wrote: >> >> On Thu, Jul 23, 2009 at 10:19 AM, Jeff Hammel<[email protected]> wrote: >> > >> PS: One of the «weaknesses» that clients suggest about using Trac is >> that global actions are not possible (i.e. actions like search, and >> plugins scope, is local to individual envs ;o) and repos creation is >> the most frequent example they point out (even if there are some ways >> to work around this ;o) > > Running the risk of thread hijacking,
Dont get it but ... > its kind of a weakness and a strength. ... here a well-known principle applies : «Give users what they want» ;) albeit if there are risks associated with it the best way is a better implementation. But «everybody else's doing it so what cant we» ;o) and my time is gold :o) > I would love to see a layer on top of what already exists that helps with > multi-project stuff. Yes of course that was the initial motivation for that. > I don't want to see any substantial alteration of existing code to enable to > the multi-project concept, as However in this case I'm not suggesting to incorporate exactly this solution into Trac core. I'm just saying that I patched Trac this way in a relative short time and saved ours of maintanance effort (users calling me to create a repo here, I dont like it do it again, I need another, blah, blah). In fact I borrowed that mechanism from TracInterfaceCustomization. There were many other directions I envisioned to enhance this - Integrate such global handlers by creating a layer (like you just said ;o) similar to trac.env.Environment but inheriting directly from trac.core.ComponentManager (AFAICR) and offer more robust implementations - Improve repos creation - ... but I couldnt even maintain the first part, so I discarded the rest ;o) > I don't think its necessary. my 0.02 > PS: There are another tactics (e.g. an special env where global actions can be implemented e.g. SF.net, USLA.AR ;o) but in this case external factors disapprove this kind of solution. For example in this case a better approach could be to have a single env (with auth roles, admin, wikis and so on), and install CreateProjectPlugin ... but still repos cannot be created in such a loosely coupled manner . That's why this approach wasnt enough in that case. -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
