Hey Loops, not sure I understand, but why can't you extend a plugin module? Overriding the actions, components, configs, or individual templates works just like overriding the model layer.. copy it up to the app level and customize.. or am I missing your point entirely?
Daniel On Nov 8, 10:21 am, Alexandru-Emil Lupu <[email protected]> wrote: > Hi! > Maybe you could write down a task or a plugin that will be able to what you > or others might need. > I guess that this functionality with a bunch of parameters is not a good > solution ... > > We had a while ago a discussion on users list, which we (some of us/ or me) > was a little bit disapointed that the symfony had a bunch of tasks that are > available.. but i dunno who need all the tasks in one single project ... > > Let's KISS symfony and add all of "extra" features as plugins ... > > Alecs > > On Sat, Nov 7, 2009 at 5:22 PM, Pierrot Evrard <[email protected]>wrote: > > > > > > > Hello, > > > I know that "my personnal usage" is not a valid argument, whatever, > > I've some trouble to create module that extends another one. > > > 1) I've my own admin generator that just extends the symfony one with > > extra-features. > > > 2) All my models and modules comes from plugins, so I just have to > > enable them in settings.yml to use them. > > > 3) Oups, I have to add a field to a model and to its module but I'm > > sure that this field will never be used in any other project. > > > 4) I can easyly add it to the model, out of the plugin, but I cannot > > create a module in my application that extends the plugin one. Ouch. > > > So, I have an idea, why not create a task that will generate a admin > > module that extends another one (with a bunch of parameter just > > because we will need some). > > > Stuff that have to be done is: > > > 1) Actions, components, helper and configuration classes will extends > > the base ones, just with some require if the autoloader is not able to > > find these last ones; > > > 2) Add some include paths to be able to find templates in the base module; > > > 3) Merge config files with the default ones when creates configuration > > cache (especially view.yml and security.yml because the generator.yml > > can be customize with the configuration class). > > > From my point of vue, the two first steps are pretty close of that the > > generator system does with the cached files, but the third step seems > > to be more difficult to implements... > > > Does it sound like a plan? Please argue. > > > Loops > > -- > Hawe a nice day! > Alecs > > As programmers create bigger & better idiot proof programs, so the universe > creates bigger & better idiots! > I am on web: http://www.alecslupu.ro/ > I am on twitter:http://twitter.com/alecslupu > I am on linkedIn:http://www.linkedin.com/in/alecslupu > Tel: (+4)0748.543.798 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" 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/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
