[Nitro] Generating scaffolding / stub codes?

Bryan Soto bryan.a.soto at gmail.com
Wed Feb 22 16:23:37 EST 2006


On 2/22/06, Bakki Kudva <bakki.kudva at gmail.com> wrote:
>
> I'd like to throw in my 2 cents worth here about rails
> plug-ins/engines. These are described in the rails environment as a
> "vertical slice of functionality" which you can just drop in your app
> and suddenly it fits and works.
>
> My experience with engines and plug-ins hasn't been quite so smooth.
> The authors make certain assumptions which may not fit and you then
> have to work around them. In the MVC stack this is particularly a
> sticking point in the Views. nItegrating them into your own views and
> still allowing for smooth upgrades of the engines is tricky. If you
> want to Ajaxify any action it adds to the problem.
>
> I think the GEM approach may be better where you leave the View part
> to the developer. For example the SENTRY gem is better I think than a
> User engine. It may not do everything a user engine would do but does
> most of the difficult parts.
>
> Ofcourse some of these problems can be avoided if lot of the features
> are configurable via options in an env file...but that makes the
> Engine developers task more difficult.
>
> Architectural guidlines set down by the core develpers may go a long
> way in making this a lot smoother for develpers as well as users.
>
> -bakki
>

I suppose you really have those problems with any extensible framework. To
give people the ability to do something useful, also gives them the ability
to wreck havoc. :)

Still, much to ponder here. I wonder if anyone has something they'd like to
try doing as a Nitro "plugin". Perhaps having something concrete would give
us  some ideas on what problems we'd need to solve.

Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060222/9bda8b50/attachment.html 


More information about the Nitro-general mailing list