Hi, At this moment, a lot of people are writing plugin''s and helpers where you would expect components to do the job. I don''t think the components are powerfull enough, they don''t provide the nessary tools for extending core functionality (you always have to write components AND plugins or make some messy plugins...). A senario, I wanted to make a fckeditor plugin that would be able to handle filemanagement (so its needs actions and views) without messing around with my application each time. I wanted the plugin that has a helper fckeditor, be able to be called from formbuilder (example form_for...|f|...f.fckeditor). And I wanted to make a behavior in ActionRecord to associate the image''s with the model (and be managed from fckeditor automaticly), something like has_many_images :book_images. I COULD do this with a implementation with plugin, but I would need to include my actions in some controller. Or I will need to write plugin and a component to get it working. I want easy manage able components and the current rails core makings this hard. I don''t say, i want you guys to do the work for me, but I need some input it would be acceptable to make components have plugin like functionality (adding something like initialise_components in the core). This is a really big problem for us as a company, we like to have some (but not to many) set of easy accessible components. We could do this by adding the path to config.plugin_paths but this could cause strange behaviour, and I don''t want to force this on other people. greets, Abdur-Rahman
Plugins can come with a generator. Thats the most user friendly way to do what you want. On 12/29/05, Abdur-Rahman Advany <rails@advany.com> wrote:> Hi, > > At this moment, a lot of people are writing plugin''s and helpers where > you would expect components to do the job. I don''t think the components > are powerfull enough, they don''t provide the nessary tools for extending > core functionality (you always have to write components AND plugins or > make some messy plugins...). > > A senario, I wanted to make a fckeditor plugin that would be able to > handle filemanagement (so its needs actions and views) without messing > around with my application each time. I wanted the plugin that has a > helper fckeditor, be able to be called from formbuilder (example > form_for...|f|...f.fckeditor). And I wanted to make a behavior in > ActionRecord to associate the image''s with the model (and be managed > from fckeditor automaticly), something like has_many_images :book_images. > > I COULD do this with a implementation with plugin, but I would need to > include my actions in some controller. Or I will need to write plugin > and a component to get it working. I want easy manage able components > and the current rails core makings this hard. I don''t say, i want you > guys to do the work for me, but I need some input it would be acceptable > to make components have plugin like functionality (adding something like > initialise_components in the core). > > This is a really big problem for us as a company, we like to have some > (but not to many) set of easy accessible components. We could do this > by adding the path to config.plugin_paths but this could cause strange > behaviour, and I don''t want to force this on other people. > > greets, > > Abdur-Rahman > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >-- Tobi http://jadedpixel.com - modern e-commerce software http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog
You can always write a plugin for this sort of thing. I plan on doing just that for the tinymce editor in the new year. http://rails-engines.rubyforge.org -Nb ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nathaniel S. H. Brown http://nshb.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> -----Original Message----- > From: rails-core-bounces@lists.rubyonrails.org > [mailto:rails-core-bounces@lists.rubyonrails.org] On Behalf > Of Abdur-Rahman Advany > Sent: December 29, 2005 4:47 PM > To: rails-core@lists.rubyonrails.org > Subject: [Rails-core] Components and Plugins > > Hi, > > At this moment, a lot of people are writing plugin''s and > helpers where you would expect components to do the job. I > don''t think the components are powerfull enough, they don''t > provide the nessary tools for extending core functionality > (you always have to write components AND plugins or make some > messy plugins...). > > A senario, I wanted to make a fckeditor plugin that would be > able to handle filemanagement (so its needs actions and > views) without messing around with my application each time. > I wanted the plugin that has a helper fckeditor, be able to > be called from formbuilder (example > form_for...|f|...f.fckeditor). And I wanted to make a > behavior in ActionRecord to associate the image''s with the > model (and be managed from fckeditor automaticly), something > like has_many_images :book_images. > > I COULD do this with a implementation with plugin, but I > would need to include my actions in some controller. Or I > will need to write plugin and a component to get it working. > I want easy manage able components and the current rails core > makings this hard. I don''t say, i want you guys to do the > work for me, but I need some input it would be acceptable to > make components have plugin like functionality (adding > something like initialise_components in the core). > > This is a really big problem for us as a company, we like to > have some (but not to many) set of easy accessible > components. We could do this by adding the path to > config.plugin_paths but this could cause strange behaviour, > and I don''t want to force this on other people. > > greets, > > Abdur-Rahman > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >
On Dec 29, 2005, at 8:57 PM, Nathaniel S. H. Brown wrote:> You can always write a plugin for this sort of thing. I plan on > doing just > that for the tinymce editor in the new year. > > http://rails-engines.rubyforge.orgYou have seen this, right? http://weblog.rubyonrails.org/articles/2005/11/11/why-engines-and- components-are-not-evil-but-distracting -- Deirdre Saoirse Moen http://deirdre.net/ deirdre@textdrive.com "Let’s make an app that does pretty pretty log log."
Of course I have :) I still stand behind my recommendation. David may be the seed by which Rails has flourished, but it is not necessarily, and it is not beneficial to follow blindly where other paths have great rewards. Engines do their purpose well, and have done well for me. If they had not, I simply would not continue to recommend using them, nor would I be at the side of James Adams with the development and future of Engines. They most definitely have their place, and it appears that it may take David a bit more time to see it. Or someone to put out an engine which puts the idea to perfect use. The login and user engines are great indeed, but they still need some work as they have not covered the areas required. When it comes to managing new versions of engines, its drop dead simple to upgrade it, in its compartment, compared to using a generator which infuses its code all over your application. Trying to upgrade the code a generator once built which now may have new models, methods, views, etc would be extremely time consuming at best. I understand where David is coming from, but there are more minds and opinions to share in the growth of the framework. -Nb ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nathaniel S. H. Brown http://nshb.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> -----Original Message----- > From: rails-core-bounces@lists.rubyonrails.org > [mailto:rails-core-bounces@lists.rubyonrails.org] On Behalf > Of Deirdre Saoirse > Sent: December 29, 2005 10:36 PM > To: rails-core@lists.rubyonrails.org > Subject: Re: [Rails-core] Components and Plugins > > On Dec 29, 2005, at 8:57 PM, Nathaniel S. H. Brown wrote: > > > You can always write a plugin for this sort of thing. I > plan on doing > > just that for the tinymce editor in the new year. > > > > http://rails-engines.rubyforge.org > > You have seen this, right? > > http://weblog.rubyonrails.org/articles/2005/11/11/why-engines-and- > components-are-not-evil-but-distracting > > -- > Deirdre Saoirse Moen http://deirdre.net/ > deirdre@textdrive.com "Let''s make an app that does pretty > pretty log log." > > > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >
On Dec 29, 2005, at 10:47 PM, Nathaniel S. H. Brown wrote:> I still stand behind my recommendation. David may be the seed by > which Rails > has flourished, but it is not necessarily, and it is not beneficial to > follow blindly where other paths have great rewards.[...]> I understand where David is coming from, but there are more minds and > opinions to share in the growth of the framework.Except, of course, this is the rails-core list. David''s already made his point on the subject. -- Deirdre Saoirse Moen http://deirdre.net/ deirdre@textdrive.com "Let’s make an app that does pretty pretty log log."
To answer Abdur''s question - as I understand it, the core team want to
keep the plugin system very simple, and while there are some
mechanisms to handle plugin ''dependencies'' (the private method
''load_plugin'', for example - I can''t find the Ticket
that discusses
this in its comments), there has also been (understandable) resistance
to implementing any form of dependency management.
If you need something more ''advanced'', you''ll need to
either make the
extensions yourself, or use something like the Engines plugin.
The point of David''s post was extolling the pitfalls of trying to
create generic components that are a *one-size-fits-all solution*
("The trouble with high-level components are solely related to making
them generic."). I don''t think anyone would disagree with that.
However, it''s important to note that you could quite easily replace
every instance of the word ''engines'' with
''generators'' or ''plugins''
and the spirit of his post would be literally untouched, since
although the scope their functionality differs, the purpose of each of
these development tools is the same: code reuse. There is simply a
balance to be found between religious adherence to the DRY principle
and writing custom code for everything.
It makes me more than a bit sad when people misunderstand what he
wrote, but then this isn''t the place to convince you otherwise.
james
On 12/30/05, Deirdre Saoirse <deirdre@textdrive.com>
wrote:>
> On Dec 29, 2005, at 10:47 PM, Nathaniel S. H. Brown wrote:
>
> > I still stand behind my recommendation. David may be the seed by
> > which Rails
> > has flourished, but it is not necessarily, and it is not beneficial to
> > follow blindly where other paths have great rewards.
>
> [...]
>
> > I understand where David is coming from, but there are more minds and
> > opinions to share in the growth of the framework.
>
> Except, of course, this is the rails-core list. David''s already
made
> his point on the subject.
>
> --
> Deirdre Saoirse Moen http://deirdre.net/
> deirdre@textdrive.com
> "Let''s make an app that does pretty pretty log log."
>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
Hi, Thnx for the responds, but I think people are misunderstanding me. I have read a lot of the blogs (including davids) about rails and I understand his hesitation to resist the development of highlevel components. I have learned a lot by making a component based framework, it just doesn''t work, components are not flexible enough and you should make everything into a component. However, there are cases where you just need to make a component to hide the complexity of implementation (thats the case with for example fckeditor). It would just be annoying to implement this for each and every application I make To start with the pointers to Engines, those things just scare me : ) they are MUCH to powerful to be used for something like components. And plugins are in some cases to weak to be used for components. I think the perfect combination would be combining components and plugins (Ticket #3357). This would allow for some (not to many) highlevel components that can be pluged into rails without to much work. However, I am not suggesting making the plugin architecture so complex that one plugin would be dependent on a other and other complex blabla. That would really make components and plugins much more complex (and hard to manage). But there is need for some more power for creating generic components. I agree that creating components like ''the perfect authentication system'' are thing that can''t never be done. Components will always service a certain group of people and won''t be the solution for everyone. Still I think, it would be ideal to have the same plugin type of behaviour applied to components... Abdur-Rahman Advany
On Dec 30, 2005, at 5:08 AM, Abdur-Rahman Advany wrote:> Thnx for the responds, but I think people are misunderstanding me.> However, there are cases where you just need to make a component to > hide the complexity of implementation (thats the case with for > example fckeditor). It would just be annoying to implement this for > each and every application I makeActually, my reply was really only to Nathaniel. I think Tobias really had a point there, though: why not a plugin and a generator?> To start with the pointers to Engines, those things just scare me : )I agree that they''re useful in the context that James Adam originally used them. In my opinion, they seem to be more useful in MIS contexts (where you''re creating pieces that will be used within a single organization, where if one instance were changed, you''d likely need to change all of them) than general widespread pieces. However, I don''t think this needs to be part of rails core, which was the motivation behind my response to Nathaniel. -- Deirdre Saoirse Moen http://deirdre.net/ deirdre@textdrive.com "Let’s make an app that does pretty pretty log log."
Generating code is something I have never liked. Its good for basic setup but hard to maintain. One of the benefits of components is that it would be easy to update them... Deirdre Saoirse wrote:> > On Dec 30, 2005, at 5:08 AM, Abdur-Rahman Advany wrote: > >> Thnx for the responds, but I think people are misunderstanding me. > >> However, there are cases where you just need to make a component to >> hide the complexity of implementation (thats the case with for >> example fckeditor). It would just be annoying to implement this for >> each and every application I make > > Actually, my reply was really only to Nathaniel. > > I think Tobias really had a point there, though: why not a plugin and > a generator? > >> To start with the pointers to Engines, those things just scare me : ) > > I agree that they''re useful in the context that James Adam originally > used them. > > In my opinion, they seem to be more useful in MIS contexts (where > you''re creating pieces that will be used within a single organization, > where if one instance were changed, you''d likely need to change all of > them) than general widespread pieces. > > However, I don''t think this needs to be part of rails core, which was > the motivation behind my response to Nathaniel. > > --Deirdre Saoirse Moen http://deirdre.net/ > deirdre@textdrive.com > "Let’s make an app that does pretty pretty log log." > > > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >
On 12/31/05, Abdur-Rahman Advany <rails@advany.com> wrote:> Generating code is something I have never liked. Its good for basic > setup but hard to maintain. One of the benefits of components is that it > would be easy to update them...Conversely, generated code is easy to modify. The assumption with components or ''reuse'' in general is that you have code you can drop in and have it ''just work''. Once you go beyond the simplest cases this gets difficult. Once you''re including user interface code it''s damned near impossible without some hideous thing with 29384739 options. plugins + generators aren''t meant for JSF style ''drop in'' components, and neither are rails'' components. Given that component is such a loaded term in this industry, could you describe what''s the requirement you have that you''re trying to solve? Perhaps there''s a simpler option available? -- Cheers Koz
Well, I will try to experiment a bit with both plugins/generators and components and see where it leads me. Ill will get back to this thread.. Michael Koziarski wrote:> On 12/31/05, Abdur-Rahman Advany <rails@advany.com> wrote: > >> Generating code is something I have never liked. Its good for basic >> setup but hard to maintain. One of the benefits of components is that it >> would be easy to update them... >> > > Conversely, generated code is easy to modify. > > The assumption with components or ''reuse'' in general is that you have > code you can drop in and have it ''just work''. Once you go beyond > the simplest cases this gets difficult. Once you''re including user > interface code it''s damned near impossible without some hideous thing > with 29384739 options. > > plugins + generators aren''t meant for JSF style ''drop in'' components, > and neither are rails'' components. Given that component is such a > loaded term in this industry, could you describe what''s the > requirement you have that you''re trying to solve? Perhaps there''s a > simpler option available? > > -- > Cheers > > Koz > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core > >