Rails - Mar 2005 - MuraveyWeb -- Ruby CMS (with demo)

Hi all,

I''m glad to announce first public release of MuraveyWeb -- Ruby CMS 
built on top of the Ruby On Rails. This is a result of my work for 
more than 4 month and I already use it in production.

# ruby code
alias :MW :MuraveyWeb

Main idea of MuraveyWeb is separation between content management and 
it''s views. With MW you can create and manage your content and then 
using MW API and Ruby On Rails you can build views to display it the 
way you like. 

Features
===== * Hierarchycal content structure stored in database
 * Supported content types: textile and HTML articles, images, files
    and user-defined key=>value documents.
 * WYSIWYG HTML editor
 * Image transformations: dynamic resizing, thumbnail generation and
    rotate tool
 * API to use all this from Ruby On Rails applications
 * JavaScript powered content browser to manage your documents and
    folders
 * Administrator interface works with Gecko browsers(Firefox, Mozilla)
    and MSIE(was tested in 6.0)
 * Simple ACL to restrict actions to the group of users

License
=====As I''m not very experienced in this question, I was looking for
the
license that will comfort everyone. For some reason I took MIT. If 
you have problems with it -- tell me.

Status
====I''ve decided to mark this version of MW 0.1.0, to show that I have
many work and features in mind for it. But it''s by no means unstable
or alpha-quality.

Demonstration
==========Note: you can play with content inside the interface, but do so with
care - don''t change password for admin user or change
mapping''s
sensitive data such as symbols. All changes will be reflected in demo
application.

* Administrator interface demo: http://tools.muravey.net
   login: admin
   password: admin

Note: demo application is just a simple example of what can be done,
but it doesn''t show full MW capabilities -- I had no time to develop
such an excessive sample right now.

* Application demo: http://demo.muravey.net
* Demo application sources: http://muravey-tools.rubyforge.org
* MW install, setup and API docs: 
http://tools.muravey.net/doc/index.html 

Random inline example
=================This is a view code in action ''news'' (Ruby On
Rails):

<% @news.iterate do |category, *| %> 
  <% for news in category %>
    <p><b><%= news.title %></b>, in <%= category.name
%>
 <font color="gray"><%= news.render_date
%></font></p>
    <p><%= mw :render => :text, :document => news %></p>
    <hr />
  <% end %>
<% end %>

Download
=======It''d be great if I could release that as a gem, but right now
that''s
kinda difficult because Rails has no support for that yet. So here 
are plain old gz''s, bz2''s and zip''s:
http://rubyforge.org/frs/?group_id=9

There''s no need to install anything after you unpacked the source.
Rename directory as you like it and follow instructions in 
doc/mw/index.html or http://tools.muravey.net/docs/index.html

If you want, you can get MW from CVS:
cvs -d:pserver:anonymous@rubyforge.org:/var/cvs/muravey-tools login
cvs -z3 -d:pserver:anonymous@rubyforge.org:/var/cvs/muravey-tools co \
 MuraveyWeb

Future plans
========* Content-based ACLs
* Search API
* Work-Flow support
* Smart pagination

Thanks
=====I''d like to say thank you to Alexander Kellett and Paul Marsh for 
their feedback with usefull comments and questions. Paul Marsh even 
sent me a patch that helped me to upgrade to Rails 0.10. Thanks guys!
I''d like to thank David Heinemeier Hansson for super-productive web 
framework that we all were waiting for.
And also, I want to thank all of you who gave me positive feedback on 
my pre-announcement.

Communication
===========If you have any problems with MW or you have idea how I can improve
it
please contact me, I will be glad to help.
There''s #MuraveyWeb IRC channel on irc.freenode.net
And forums on the RubyForge: http://rubyforge.org/forum/?group_id=9

Bugs
===You can report any bugs or misbehaviors here: 
http://rubyforge.org/tracker/?group_id=9

-- 
sdmitry -=- Dmitry V. Sabanin
http://muravey.net

Congratulations Dmitry! 

I''ve been playing for a while (i''m the ''foo''
user and ''books editor''
role creator, hope that''s ok ;-) and it seems really cool and easy to 
work with.

We''re working in (yet) another multiuser blogging tool
(lacoctelera.com,
public since last friday, still under strict surveillance) and your 
project looks nice to add our currently missed features.

Thanks a lot to all RoR folks like you.

Let''s continue rolling!

Nando .


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Bonjour Dmitry,
> I''m glad to announce first public release of MuraveyWeb -- Ruby
CMS
> built on top of the Ruby On Rails. This is a result of my work for 
> more than 4 month and I already use it in production.
Congratulations for your nice work,

-- 
Gretz
 mathieu

On Monday, March 14, 2005, 7:34:31 PM, Dmitry wrote, in part:
> There''s no need to install anything after you unpacked the source.
> Rename directory as you like it and follow instructions in 
> doc/mw/index.html or http://tools.muravey.net/docs/index.html
That docs link is broken :(

Seems common for Rails-based websites to have some loose ends with
ugly errors.  Probably not Rails'' fault at all, just (in this case)
some routing error or (more commonly) a database error.  But perhaps
Rails can help by being able to create a more end-user-friendly error
page or something.

Gavin

Gavin Sinclair wrote:
> Seems common for Rails-based websites to have some loose ends with
> ugly errors.  Probably not Rails'' fault at all, just (in this
case)
> some routing error or (more commonly) a database error.  But perhaps
> Rails can help by being able to create a more end-user-friendly error
> page or something.
The error page seems quite informative.  What''s the problem?
Troll much?

jeremy

On Tuesday, March 15, 2005, 9:02:28 AM, Jeremy wrote:
> Gavin Sinclair wrote:
>> Seems common for Rails-based websites to have some loose ends with
>> ugly errors.  Probably not Rails'' fault at all, just (in this
case)
>> some routing error or (more commonly) a database error.  But perhaps
>> Rails can help by being able to create a more end-user-friendly error
>> page or something.
> The error page seems quite informative.  What''s the problem?
> Troll much?
Fuck you, twit.  The error page is informative for a developer, not an
end user who''s wondering why the page they''ve been linked to
is
broken.  Yes, _I_ know what a routing error is, but it doesn''t hurt to
look at an application from the point of view of the poor _users_ once
in a while, does it?

Sorry for suggesting an improvement.

Gavin

On Mon, Mar 14, 2005 at 02:02:28PM -0800, Jeremy Kemper
wrote:
> Gavin Sinclair wrote:
> > Seems common for Rails-based websites to have some loose ends with
> > ugly errors.  Probably not Rails'' fault at all, just (in this
case)
> > some routing error or (more commonly) a database error.  But perhaps
> > Rails can help by being able to create a more end-user-friendly error
> > page or something.
> 
> The error page seems quite informative.  What''s the problem?
> Troll much?
> 
> jeremy
It doesn''t work for me either and I''m not a troll,
I''m an extremely
tall balding Gnome :-) 

Eric
-- 
------------------------------------------------------------------------
#  Eric A Lucas                        |             __|__
#   "Oh, I have slipped the surly bond |          *---oOo---*
#    of earth and danced the skies on  |    __|__             __|__
#    laughter-silvered wings...        | *---oOo---*       *---oOo---*
#        -- John Gillespie Magee Jr.   |

On Tue, 15 Mar 2005, Gavin Sinclair wrote:
> On Tuesday, March 15, 2005, 9:02:28 AM, Jeremy wrote:
>
>> Gavin Sinclair wrote:
>>> Seems common for Rails-based websites to have some loose ends with
>>> ugly errors.  Probably not Rails'' fault at all, just (in
this case)
>>> some routing error or (more commonly) a database error.  But
perhaps
>>> Rails can help by being able to create a more end-user-friendly
error
>>> page or something.
>
>> The error page seems quite informative.  What''s the problem?
>> Troll much?
>
> Fuck you, twit.  The error page is informative for a developer, not an
> end user who''s wondering why the page they''ve been linked
to is
> broken.  Yes, _I_ know what a routing error is, but it doesn''t
hurt to
> look at an application from the point of view of the poor _users_ once
> in a while, does it?
>
> Sorry for suggesting an improvement.
easy there gavin, keep in mind these guys have essentially been under attack
for quite some time and are probably a bit trigger happy.  and too
caffinated...

google ''java ruby rails blog'' and you''ll see exactly
what i mean.  that being
said - it was over the top.

kind regards.

-a
-- 
==============================================================================|
EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE   :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself.  --Shunryu Suzuki
===============================================================================

On Mon, 14 Mar 2005 14:02:28 -0800, Jeremy Kemper
<jeremy-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org>
wrote:
> Gavin Sinclair wrote:
> > Seems common for Rails-based websites to have some loose ends with
> > ugly errors.  Probably not Rails'' fault at all, just (in this
case)
> > some routing error or (more commonly) a database error.  But perhaps
> > Rails can help by being able to create a more end-user-friendly error
> > page or something.
> 
> The error page seems quite informative.  What''s the problem?
> Troll much?
You were kidding, right?
http://www.google.com/search?q=%2B%22gavin+sinclair%22+%2Bruby

If you guys want to hear suggestions for improving it, might want to
put a safety lock on that hair trigger.

I agree with Gavin btw, the error pages could be "cleaner".  Just hide
the error data, or dump/trace options, behind a "show error details"
link.  Could make it a config option, or have it behave appropriately
based on dev/test/prod mode.

-- 
Bill Guindon (aka aGorilla)

> I agree with Gavin btw, the error pages could be "cleaner".  Just
hide
> the error data, or dump/trace options, behind a "show error
details"
> link.  Could make it a config option, or have it behave appropriately
> based on dev/test/prod mode.
That is already so. When a application is running in the production 
environment, users are automatically redirected to public/500.html on 
errors. In the development environment, though, all requests get full 
debugging information.

It would appear that the app was launched running the development 
environment. Which also reloads the app every time and turns off 
caching. You can make the app run in production mode by making sure 
that RAILS_ENV is set to "production".

In webrick, this is done with -e. In FastCGI, it''s done with 
-initial-env RAILS_ENV.
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain

On Tuesday, March 15, 2005, 9:27:35 AM, Bill wrote:
> Could make it a config option, or have it behave appropriately
> based on dev/test/prod mode.
That mode-sensitivity is a good idea.  In production, the user doesn''t
need more than "Internal Server Error" and a link to the site home.
Making the details available helps too.  An automatic email to the
developer when there''s a production error would be good, and a note to
that effect on the error page ("The web administrator is being
informed...").

Also, some easy way of (unit?) testing all the no-brainer pages, like:

  assert_sane_response( %w[
    /index.html /doc/index.html /about.html ...
  ])

Cheers,
Gavin

On Mon, 14 Mar 2005 23:34:12 +0100, David Heinemeier Hansson
<david-OiTZALl8rpK0mm7Ywyx6yg@public.gmane.org>
wrote:
> > I agree with Gavin btw, the error pages could be "cleaner". 
Just hide
> > the error data, or dump/trace options, behind a "show error
details"
> > link.  Could make it a config option, or have it behave appropriately
> > based on dev/test/prod mode.
> 
> That is already so. When a application is running in the production
> environment, users are automatically redirected to public/500.html on
> errors. In the development environment, though, all requests get full
> debugging information.
Good to know (and nicely done, as expected).
 
> It would appear that the app was launched running the development
> environment. Which also reloads the app every time and turns off
> caching. You can make the app run in production mode by making sure
> that RAILS_ENV is set to "production".
> 
> In webrick, this is done with -e. In FastCGI, it''s done with
> -initial-env RAILS_ENV.
Ok, so simple mistake on the part of the site owner.  If nothing else,
bet this thread reduces the odds of that happening again :)

-- 
Bill Guindon (aka aGorilla)

>>> Seems common for Rails-based websites to have some loose ends with
>>> ugly errors.
>> The error page seems quite informative.  What''s the problem?
>> Troll much?
>
> Fuck you, twit.  The error page is informative for a developer, not an
> end user who''s wondering why the page they''ve been linked
to is
> broken.
While Jeremy may have been quick on the troll alert (the quoted 
statement did sound very trollish, though), this is uncalled for, 
Gavin.

I''ve supplied information on the cause and remedy to this issue else 
where in the thread, but I just wanted to make a statement that this is 
not acceptable behavior.
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain

On Tuesday, March 15, 2005, 9:39:13 AM, David wrote:
>>>> Seems common for Rails-based websites to have some loose ends
with
>>>> ugly errors.
>>> The error page seems quite informative.  What''s the
problem?
>>> Troll much?
>>
>> Fuck you, twit.  The error page is informative for a developer, not an
>> end user who''s wondering why the page they''ve been
linked to is
>> broken.
> While Jeremy may have been quick on the troll alert (the quoted 
> statement did sound very trollish, though), this is uncalled for, 
> Gavin.
"very trollish"???  I''d be a pretty poor troll if that were
the best I
could do.
> I''ve supplied information on the cause and remedy to this issue
else
> where in the thread, but I just wanted to make a statement that this is
> not acceptable behavior.
So be it.  If I''m called a troll again, it will likely happen again.

Gavin

> "very trollish"???  I''d be a pretty poor troll if that
were the best I
> could do.
It _sounded_ trollish. That does not you a troll make ;). And I know 
you''re not a troll, but if one was not familiar with your name from 
other dealings, I could see how quick conclusions could be drawn.

Anyway, as we''ve sorted out, Rails already has amble support for 
distinguishing between user and developer -- but of course they need to 
be turned on.

So hopefully the storm is a cup will have brought attention to this 
functionality if nothing else.

Welcome to Rails, Gavin.
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain

Gavin Sinclair wrote:
> On Tuesday, March 15, 2005, 9:02:28 AM, Jeremy wrote:
>>Gavin Sinclair wrote:
>>>Seems common for Rails-based websites to have some loose ends with
>>>ugly errors.  Probably not Rails'' fault at all, just (in
this case)
>>>some routing error or (more commonly) a database error.  But perhaps
>>>Rails can help by being able to create a more end-user-friendly
error
>>>page or something.
> 
>>The error page seems quite informative.  What''s the problem?
>>Troll much?
> 
> Fuck you, twit.  The error page is informative for a developer, not an
> end user who''s wondering why the page they''ve been linked
to is
> broken.  Yes, _I_ know what a routing error is, but it doesn''t
hurt to
> look at an application from the point of view of the poor _users_ once
> in a while, does it?
> 
> Sorry for suggesting an improvement.
I apologize for the hasty conclusion, Gavin.  We aren''t the nerviest
bunch.  You have a valid suggestion but prefaced it with inflammatory
commentary and delivered it with a negative tone.

Typically I would respond with the constructive explanation that the
thread deserves, but I interpreted your words as a passive-aggressive
jab, not as constructive criticism, and hypocritically responded in
kind.  My bad.

Rails has the concept of environments to represent the stages of an
application''s lifecycle: test, development, and production are the
defaults.  Specify your choice with the RAILS_ENV environment variable.
 Each environment has a corresponding config/environments/name.rb with
its particular config code.

Errors are handled as appropriate for the deployment target.  The test
and development environments provide developer-relevant error handling
whereas the production environment returns an error page with HTTP
status 500 (Application Error).

Best,
jeremy

Dear Dmitry, 

I took the liberty of "announcing" your nice app on my
blog here : 

http://www.iosn.net/Members/platypus/blog/42#more

Hopefully you approve. Great app ! Congratulations ! 

--- "Dmitry V. Sabanin" <sdmitry-okj3p8EEQC8@public.gmane.org>
wrote:
> Hi all,
> 
> I''m glad to announce first public release of
> MuraveyWeb -- Ruby CMS 
> built on top of the Ruby On Rails. This is a result
> of my work for 
> more than 4 month and I already use it in
> production.
> 
> # ruby code
> alias :MW :MuraveyWeb
> 
> Main idea of MuraveyWeb is separation between
> content management and 
> it''s views. With MW you can create and manage your
> content and then 
> using MW API and Ruby On Rails you can build views
> to display it the 
> way you like. 
> 
> Features
> =====>  * Hierarchycal content structure stored in database
>  * Supported content types: textile and HTML
> articles, images, files
>     and user-defined key=>value documents.
>  * WYSIWYG HTML editor
>  * Image transformations: dynamic resizing,
> thumbnail generation and
>     rotate tool
>  * API to use all this from Ruby On Rails
> applications
>  * JavaScript powered content browser to manage your
> documents and
>     folders
>  * Administrator interface works with Gecko
> browsers(Firefox, Mozilla)
>     and MSIE(was tested in 6.0)
>  * Simple ACL to restrict actions to the group of
> users
> 
> License
> =====> As I''m not very experienced in this question, I was
> looking for the 
> license that will comfort everyone. For some reason
> I took MIT. If 
> you have problems with it -- tell me.
> 
> Status
> ====> I''ve decided to mark this version of MW 0.1.0, to
> show that I have
> many work and features in mind for it. But it''s by
> no means unstable
> or alpha-quality.
> 
> Demonstration
> ==========> Note: you can play with content inside the
> interface, but do so with
> care - don''t change password for admin user or
> change mapping''s
> sensitive data such as symbols. All changes will be
> reflected in demo
> application.
> 
> * Administrator interface demo:
> http://tools.muravey.net
>    login: admin
>    password: admin
> 
> Note: demo application is just a simple example of
> what can be done,
> but it doesn''t show full MW capabilities -- I had no
> time to develop
> such an excessive sample right now.
> 
> * Application demo: http://demo.muravey.net
> * Demo application sources:
> http://muravey-tools.rubyforge.org
> * MW install, setup and API docs: 
> http://tools.muravey.net/doc/index.html 
> 
> Random inline example
> =================> This is a view code in action
''news'' (Ruby On
> Rails):
> 
> <% @news.iterate do |category, *| %> 
>   <% for news in category %>
>     <p><b><%= news.title %></b>, in <%>
category.name %>
>  <font color="gray"><%= news.render_date
> %></font></p>
>     <p><%= mw :render => :text, :document => news
> %></p>
>     <hr />
>   <% end %>
> <% end %>
> 
> Download
> =======> It''d be great if I could release that as a gem, but
> right now that''s 
> kinda difficult because Rails has no support for
> that yet. So here 
> are plain old gz''s, bz2''s and zip''s:
> http://rubyforge.org/frs/?group_id=9
> 
> There''s no need to install anything after you
> unpacked the source.
> Rename directory as you like it and follow
> instructions in 
> doc/mw/index.html or
> http://tools.muravey.net/docs/index.html
> 
> If you want, you can get MW from CVS:
> cvs
>
-d:pserver:anonymous-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org:/var/cvs/muravey-tools
> login
> cvs -z3
>
-d:pserver:anonymous-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org:/var/cvs/muravey-tools
> co \
>  MuraveyWeb
> 
> Future plans
> ========> * Content-based ACLs
> * Search API
> * Work-Flow support
> * Smart pagination
> 
> Thanks
> =====> I''d like to say thank you to Alexander Kellett and
> Paul Marsh for 
> their feedback with usefull comments and questions.
> Paul Marsh even 
> sent me a patch that helped me to upgrade to Rails
> 0.10. Thanks guys!
> I''d like to thank David Heinemeier Hansson for
> super-productive web 
> framework that we all were waiting for.
> And also, I want to thank all of you who gave me
> positive feedback on 
> my pre-announcement.
> 
> Communication
> ===========> If you have any problems with MW or you have idea
> how I can improve it 
> please contact me, I will be glad to help.
> There''s #MuraveyWeb IRC channel on irc.freenode.net
> And forums on the RubyForge:
> http://rubyforge.org/forum/?group_id=9
> 
> Bugs
> ===> You can report any bugs or misbehaviors here: 
> http://rubyforge.org/tracker/?group_id=9
> 
> -- 
> sdmitry -=- Dmitry V. Sabanin
> http://muravey.net
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/

On Tuesday 15 March 2005 04:55, Gavin Sinclair wrote:
> On Monday, March 14, 2005, 7:34:31 PM, Dmitry wrote, in part:
> > There''s no need to install anything after you unpacked the
> > source. Rename directory as you like it and follow instructions
> > in doc/mw/index.html or http://tools.muravey.net/docs/index.html
>
> That docs link is broken :(
Sorry, I gave you the wrong URL. Right one is 
http://tools.muravey.net/doc/index.html
I thought I corrected it before announcement, and I did:
  * MW install, setup and API docs: 
  http://tools.muravey.net/doc/index.html

But I forgot to change it in another place. Sorry for all this!
> Seems common for Rails-based websites to have some loose ends with
> ugly errors.
That''s entirely my mistake :(
> Gavin
-- 
sdmitry -=- Dmitry V. Sabanin
http://muravey.net

Jeremy wrote:
> I apologize for the hasty conclusion, Gavin.  We aren''t the
nerviest
> bunch.  You have a valid suggestion but prefaced it with inflammatory
> commentary and delivered it with a negative tone.
>
> Typically I would respond with the constructive explanation that the
> thread deserves, but I interpreted your words as a passive-aggressive
> jab, not as constructive criticism, and hypocritically responded in
> kind.  My bad.
And I apologise for my outburst.  No grudges from this end, don''t worry
:)

To justify the "inflammatory" comment, though, I have visited several
websites that I know to be Rails-based, and it often happens that
there''s
an error of some kind (usually database-related).  Sometimes it''s
transient.  I never blamed Rails for any of this; it''s just an artefact
of
quick implementations and/or unreliable hosting (perhaps).  It''s *good*
to
see so many Rails-based apps up and running so quickly, but I''d rather
comment on the error pages I see, rather than leave that observation for
people looking to kick Rails.

Anyway, I already knew most of the facts presented in this thread, but I
think more could be done, as I''ve outlined elsewhere.  I think the
problem
with the Muravey docs page was one of static content being thwarted by
dynamic routing.  Since the author of a webapp probably knows all of the
static pages, a functional test that they are being served correctly would
help avoid that problem.  (That routing issue had especial resonance with
me, having struggled with it before.)

Database problems are obviously a different story, though.

Cheers,
Gavin