On Dec 2, 1:46 pm, "Yariv Sadan" <[EMAIL PROTECTED]> wrote:
> On Dec 1, 2007 10:24 PM, Robin <[EMAIL PROTECTED]> wrote:
>
>
>
> > Here are some ideas:
>
> > * Flexible routes
>
> What do flexible routes do exactly? I know that Rails has some routes
> config file, but ErlyWeb gives you full control -- in Erlang -- over
> how requests are routed using the app controller. You also have the
> before_call controller hook. Is there anything missing?
Rails uses a DSL for mapping routes to controllers,actions, and
params, so you can concisely make clean and hackable urls like /posts/
2007/12/02, /posts/tag/holiday, and REST resources. The basic idea is
to provide more structure, so that everyone does not have to implement
their own custom route system.
>
> > * Standardized script interface (for migrations, generators/templates,
> > tests, maintenance tasks )
>
> I'm open to suggestions here.
>
>
Currently, erlyweb uses erlang for scripting tasks like generators
etc, but maybe doing the scripting with a scripting language would be
a better fit.
>
>
>
> > I know a bit about Rails plugins...the main benefit is providing a
> > standard way for people to share functionality in the vein of
> > "convention over configuration".
>
> > Plugins are created with "script/generate plugin my_widget", which
> > creates a default plugin structure under vendor/plugins/my_widget.
>
> > Plugins have standard hooks like install.rb which is run when the
> > plugin is installed, and init.rb which is run when the plugin is
> > initialized.
>
> > A plugin's lib/ is automatically added to the include path, tasks/ are
> > automatically added to rake's include path, and test/ is added to the
> > test suite.
>
> > Plugins are stored in svn and you can install third party plugins with
> > "script/plugin installhttp://site.com/my_widget"; which does an svn
> > checkout to your app's vendor/plugins directory.
>
> > Plugins are good for quick code sharing where someone publishes a blog
> > post explaining their new plugin, and you can easily install and
> > evaluate it.
>
> > The downside of plugins is that most are generally unversioned, and
> > most developers serve plugins directly from trunk/ so it is hard to
> > track dependencies, compatibility, and updates.
>
> > The Merb framework which attempts the be Rails only faster and better
> > uses ruby gems (gems are ruby packages) for plugins which provides for
> > versioning an dependencies.
>
> > For Erlyweb, instead of creating a one-off plugin system like Rails,
> > it might be better to use a package system to handle dependencies and
> > provide versioning.
>
> These sound like good features. I guess the only "plugin" ErlyWeb
> currently has is the erlang2facebook library, which you have to
> install manually in your app directory (which is pretty easy,
> actually). I think a fully fledged plugin system would be useful if
> people started creating more and more such addons and maintenance
> became a problem, but I'm not seeing a lot of other addons being
> developed so a full plugin system may not be needed right now. That
> said, if more people start creating such addons I'll be happy to make
> their integration easier in ErlyWeb.
>
> Also, don't some plugins rely on migration support to modify the
> schema on installation?
Plugins do not migrate or modify the schema directly. Plugins often
provide generators that the developer uses to generate migration
files. The developer then does a "rake db:migrate" to actually apply
any new migrations.
Components are vertical slices of functionality. Plugins should also
add horizontal slices of functionality, but that is harder to
accomplish with a compiled language. I think Smerl could be used to
cleverly add horizontal functionality via plugins, but they key is
having a standard ized way for smerl to mixin behavior into existing
modules.
Maybe plugins are a chicken and egg problem...the reason no body
creates libs for erlyweb is because there is no standard way to share
such libs. Perhaps a standard plugin structure would encourage folks
to share their libs, and lead to a proliferation of contribution.
Rails gradually got bigger and bigger up to version 1.2.x, and the
soon to be released Rails 2.0 does not add much new functionality,
instead it pulled all the non-vital stuff out to plugins. Therefore,
the core can remain small, and features can be added with plugins.
>
> Thanks,
> Yariv
>
>
>
> > Robin
>
> > On Dec 1, 8:42 pm, David King <[EMAIL PROTECTED]> wrote:
> > > > Also, we should start planning the next release. What features do you
> > > > think will be most useful (web services support is on the list)?
>
> > > * Database migrations
>
> > > * Plugin support
>
> > > Rails has the ability to plug in an entire login system, or OpenID
> > > system, or forum system, into your app all at once, by installing it
> > > and setting up the hooks. This would make it easier to write this
> > > code once. I'm not a heavy user of Rails, so I don't know how this
> > > works.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"erlyweb" 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/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
