Rails - Jul 2005 - let the battle begin: Django

Looks like a worthy competitor is arriving on the scene (but not all the
way through the door yet...)

http://www.djangoproject.com/



-- 

________________________________
toddgrimason*todd[ at ]slack.net

Hi All,

I was wondering if anyone has suggestions for development tools in  
OSX... more specifically, which editor is DHH using in the Rails Take  
2 Movie?
http://www.loudthinking.com/arc/000232.html

-Alan
6sides.com

On 14-Jul-05, at 11:27 PM, Todd Grimason wrote:
> Looks like a worthy competitor is arriving on the scene (but not  
> all the
> way through the door yet...)
>
> http://www.djangoproject.com/
>
>
>
> -- 
>
> ________________________________
> toddgrimason*todd[ at ]slack.net
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

yikes, sorry about the terrible post etiquette... readable title and  
no wasted message body this time....

--Alan
> Hi All,
>
> I was wondering if anyone has suggestions for development tools in  
> OSX... more specifically, which editor is DHH using in the Rails  
> Take 2 Movie?
> http://www.loudthinking.com/arc/000232.html
>
> -Alan
> 6sides.com

On Jul 15, 2005, at 12:43 AM, Alan McLean wrote:
>> Hi All,
>>
>> I was wondering if anyone has suggestions for development tools in  
>> OSX... more specifically, which editor is DHH using in the Rails  
>> Take 2 Movie?
>> http://www.loudthinking.com/arc/000232.html
>>
>
It''s probably TextMate from Macromates.com.

I highly recommend it.

Duane Johnson
(canadaduane)

yup, that appears to be it, thank you!

--Alan
6sides.com

On 15-Jul-05, at 12:23 AM, Duane Johnson wrote:
>
> On Jul 15, 2005, at 12:43 AM, Alan McLean wrote:
>
>>> Hi All,
>>>
>>> I was wondering if anyone has suggestions for development tools  
>>> in OSX... more specifically, which editor is DHH using in the  
>>> Rails Take 2 Movie?
>>> http://www.loudthinking.com/arc/000232.html
>>>
>>>
>>
>>
>
> It''s probably TextMate from Macromates.com.
>
> I highly recommend it.
>
> Duane Johnson
> (canadaduane)
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

He is using "Textmate, the missing editor for OS X" ;-) (
http://macromates.com/)

Colomain.

On 7/15/05, Alan McLean <alan_mclean-ee4meeAH724@public.gmane.org>
wrote:
> 
> Hi All,
> 
> I was wondering if anyone has suggestions for development tools in
> OSX... more specifically, which editor is DHH using in the Rails Take
> 2 Movie?
> http://www.loudthinking.com/arc/000232.html
> 
> -Alan
> 6sides.com <http://6sides.com>
> 
> On 14-Jul-05, at 11:27 PM, Todd Grimason wrote:
> 
> > Looks like a worthy competitor is arriving on the scene (but not
> > all the
> > way through the door yet...)
> >
> > http://www.djangoproject.com/
> >
> >
> >
> > --
> >
> > ________________________________
> > toddgrimason*todd[ at ]slack.net
> >
> >
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

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

Competition is a great thing.

I''d love it if there was a Rails equivalent that focused on legacy
integration instead of focusing on pluralisation and imposing it''s own
database world view.  The golden path is lined with barbed wire and if you
step off the golden path then you are truly off the rails and into the
minefield.

Rails feels like a Formula 1 in a smash up derby.  Any time you want to wind
it up to full speed you immediately start smashing into restrictions and
limitations imposed by the need to walk the golden path.

It''s such a puzzle why there should be a golden path instead of a
simple and
effective mechanism to describe your databases which rails then utilises and
honours.  As things stand, "if Rails can''t guess it then Rails
can''t use it"
http://dev.rubyonrails.com/ticket/913.  Without the golden path, Rails would
be truly flexible and powerful.

Perhaps someone (with more brainpower than my meager allocation) should fork
Rails and create "Enterprise Rails" which chops out the golden path
and
instead focuses on integrating with databases of any structure and makes no
assumptions about table and field names.  What''s the point in OR
mapping if
you have to name fields and tables in certain ways to make the map
meaningful?

For example I didn''t spend today in coding bliss with Rails, with a
direct
connection between ideas and code.  Instead I spent the day trying to work
out how to get around the fact that Rails won''t generate Scaffold code
if
you don''t use golden path table names
http://dev.rubyonrails.com/ticket/913.
Without generated code I''m having to dive deep and hack files and copy
things back and forth to try to work out how to construct a page that works.
I still don''t have anything that works and its the end of the day. 
Where''s
the bliss in that - it''s just the same as any other development
technology -
they all seem to force you to start hacking around their limitations almost
immediately.

Sorry to be such a (loud) whiner about it but I''m really caught between
wanting to love Rails and hating it''s needless dogma and frustrating
and
needless restrictions and limitations.   Spending an entire day trying to
hack around pointless limitations leads to cynicsm.  Am I alone in thinking
these things?  Does anyone else think there should be an "Enterprise
Rails"
for building real systems instead of toys?  It''s a pity django
isn''t wriiten
in Ruby.

Anyone care to argue the other side of the case?  I haven''t yet heard
any
good arguments for why the golden path is a "good thing" and why there
is no
need for flexibility in database integration.  If everyone thinks I''m
mad
then you''ll hear no more whining on this subject from me.

Andrew




----- Original Message ----- 
From: "Todd Grimason"
<todd-cwT7Wi5Y1r1eoWH0uzbU5w@public.gmane.org>
To: <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org>
Sent: Friday, July 15, 2005 4:27 PM
Subject: [Rails] let the battle begin: Django


Looks like a worthy competitor is arriving on the scene (but not all the
way through the door yet...)

http://www.djangoproject.com/



-- 

________________________________
toddgrimason*todd[ at ]slack.net


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

Andrew Stuart wrote:
>Sorry to be such a (loud) whiner about it but I''m really caught
between
>wanting to love Rails and hating it''s needless dogma and
frustrating and
>needless restrictions and limitations.   Spending an entire day trying to
>hack around pointless limitations leads to cynicsm.  Am I alone in thinking
>these things?  Does anyone else think there should be an "Enterprise
Rails"
>for building real systems instead of toys?  It''s a pity django
isn''t wriiten
>in Ruby.
>  
>
It is certainly frustrating when you sometimes have to spend entire day 
working on a simple
thing, but no matter which framework you choose you always hit such 
"obstacles".
Rails is certainly not "golden" but it makes life easier for some
people.
These "needless" restrictions are in fact needed to get rid of xml
files
describing
DB structure (which is the case in for example Hibernate), Rails follows 
the path: "what''s the point
of describing DB structure if I can read it myself", which I personally 
think is a good way
to go. But you can still describe the db structure yourself.
I don''t think there is a point to judging Rails as a "toy" or
"enterprise framework".
There are lots of OS frameworks considered "enterprise  level". Just 
choose  the one which
suits your needs best and create something out from it.

I personally saw "enterprise systems" running on no framework at all
:-)
My friend thinks C is best for writing web apps because it is damn fast
and PHP sucks because it sorts arrays a couple times slower than Java, 
so there''s
really no way to tell "this one is the best" and satisfy everyone.

Greeting from sunny Krakow, Poland. :)

--
Best
Karol Hosiawa

Andrew Stuart wrote:
> Competition is a great thing.
> 
> I''d love it if there was a Rails equivalent that focused on legacy
> integration instead of focusing on pluralisation and imposing it''s
own
> database world view.  The golden path is lined with barbed wire and if you
> step off the golden path then you are truly off the rails and into the
> minefield.
> 
[snip]

I think Andrew has a valid point here. Scaffolding is reserved for new 
applications that are setup following the rails rules.

But technically it should be possible to generate models/scaffolds on 
legacy databases, the only difference being that the generator would add 
tablenames and primary key names to the models, and loose pluralization. 
Or am I missing something crucial here? Maybe with the help of an extra 
switch on the generate command?

Also, I think the mentioned problems are also to lack of documentation 
on this point (or maybe not lack, but uneasy to find documentation). It 
would be nice to have the "golden path" explained exactly in a simple 
bulleted list, with an explanation of what should be done manually if 
you need to support a legacy database. This bulleted list should be 
somewhere in a spot where a newbie would easily find it (not somewhere 
deep in the wiki).

As I have only worked with legacy stuff and rails I can write up the 
steps I take to get legacy stuff working, maybe someone else can add the 
list of conventions that need to be followed for getting a working 
scaffold with a new setup?

Maybe it''s just a matter of rearranging info that''s already
scattered
over the wiki into an easy to find page...

regards,
Bas

Hi Andrew,

It''s definently more work in Rails to use a legacy database, but it
certainly still can be done. Depending on how "legacy" it is, you can
turn off name pluralisation and set table names. If that''s not enough,
the worst case scenario is that you code your own SQL queries into
methods in the model. Using this technique Rails can work with any
database schema.

If you spent the better part of a day trying to figure out how to make
a few pages work without the ''scaffold'' generator then I would
really
suggest you point your browser to
http://www.pragmaticprogrammer.com/titles/rails/index.html and
purchase the book.

I''d also just like to point out that the Rails magic comes through
''convention over configuration''. It allows the framework to
remain
simple whilst being extremely powerful. This focus makes life much
easier for the majority of the framework''s users. It may slow down a
small minority, but if Rails tries to accomodate everyone it will lose
its simplicity and much of its allure.

Ben

On 7/15/05, Andrew Stuart
<andrew.stuart-TWq/lk6o2i4FZYWR8B6FNDvXrrhHudLZEK66K81epY8@public.gmane.org>
wrote:
...
> Rails feels like a Formula 1 in a smash up derby.  Any time you want to
wind
> it up to full speed you immediately start smashing into restrictions and
> limitations imposed by the need to walk the golden path.
...

I''d definitely be interested in seeing something like this. In
particular I''d like an easy way to remove the requirement that
dependent objects with a belongs_to relationship have a primary key as
well as the foreign key.

Cheers,
Colin

On 7/15/05, Bas van Klinkenberg
<lists-JQ6x5Nlb7DGNzEXqMhSRc45ogaMWVTX7Zkel5v8DVj8@public.gmane.org>
wrote:
> Andrew Stuart wrote:
> > Competition is a great thing.
> >
> > I''d love it if there was a Rails equivalent that focused on
legacy
> > integration instead of focusing on pluralisation and imposing
it''s own
> > database world view.  The golden path is lined with barbed wire and if
you
> > step off the golden path then you are truly off the rails and into the
> > minefield.
> >
> [snip]
> 
> I think Andrew has a valid point here. Scaffolding is reserved for new
> applications that are setup following the rails rules.
> 
> But technically it should be possible to generate models/scaffolds on
> legacy databases, the only difference being that the generator would add
> tablenames and primary key names to the models, and loose pluralization.
> Or am I missing something crucial here? Maybe with the help of an extra
> switch on the generate command?
> 
> Also, I think the mentioned problems are also to lack of documentation
> on this point (or maybe not lack, but uneasy to find documentation). It
> would be nice to have the "golden path" explained exactly in a
simple
> bulleted list, with an explanation of what should be done manually if
> you need to support a legacy database. This bulleted list should be
> somewhere in a spot where a newbie would easily find it (not somewhere
> deep in the wiki).
> 
> As I have only worked with legacy stuff and rails I can write up the
> steps I take to get legacy stuff working, maybe someone else can add the
> list of conventions that need to be followed for getting a working
> scaffold with a new setup?
> 
> Maybe it''s just a matter of rearranging info that''s
already scattered
> over the wiki into an easy to find page...
> 
> regards,
> Bas
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

> What''s the point in OR mapping if
> you have to name fields and tables in certain ways to make the map
> meaningful?
Your frustration seems like it might be one of mismatched
expectations. Rails uses the Active Record pattern for ORM, which
trades freedom of mapping for less software (and configuration). Your
situation might be calling for a full-fledged data mapper if you''re
feeling too much pain bending Active Record. Fowler has a good
description on the differences in Patterns of Enterprise Application
Architecture.

But I don''t know your schema. Maybe it''s not so legacy as
being unable
for Active Record to bend to. But you seem intent on focusing your
rant on whether one feature of Rails (the scaffolding generator) will
bend all the way or not. I bet you could have recreated the code the
scaffolding generator does for you three times over in the time it
took you to write this. There are quite a few tutorials out there to
help you. And even a book now.

"Without the golden path, Rails would be truly flexible and powerful".
Heh. The golden path is also what we call "Convention over
Configuration". One of the most lauded aspects of Rails. It allows you
to trade idiosyncrasies for productivity. Learn a handful of
conventions and you''ll never have to specify their consequences
explicitly again.

I tend to view "truly flexible" by another term: "Make everything
equally hard".

All this being said, Active Record does, as stated above, bend. Lots
of people have found that it has been easier to bend AR rather than
switch to a full data mapper. I suggest you give it a try. We have a
community available here on the mailing list and on the IRC channel to
help you with specific issues. And there''s the ticket system to report
outright breakage.

Of course, getting help will be much easier if you''re willing to
accept that you perhaps don''t yet appreciate why all of the design
choices in Rails came out as they did. If you do, your "hate" for
"needless dogma", "needless restrictions", and 
"pointless
limitations" might be replaced by curiosity. Could it be that needless
in another light is helpful? Could it be that restrictions from a
different perspective is liberating?

I believe that if you open your mind the rest will follow.

Welcome to Rails.
-- 
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

How is he getting tabs on the Terminal window? And is all that autocomplete 
stuff for Rails built into Textmate?

On 7/15/05, Colomain <colomain-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 
> He is using "Textmate, the missing editor for OS X" ;-) (
> http://macromates.com/)
> 
> Colomain.
> 
> On 7/15/05, Alan McLean <alan_mclean-ee4meeAH724@public.gmane.org>
wrote:
> > 
> > Hi All,
> > 
> > I was wondering if anyone has suggestions for development tools in
> > OSX... more specifically, which editor is DHH using in the Rails Take
> > 2 Movie?
> > http://www.loudthinking.com/arc/000232.html
> > 
> > -Alan
> > 6sides.com <http://6sides.com>
> > 
> > On 14-Jul-05, at 11:27 PM, Todd Grimason wrote:
> > 
> > > Looks like a worthy competitor is arriving on the scene (but not 
> > > all the
> > > way through the door yet...)
> > >
> > > http://www.djangoproject.com/
> > >
> > >
> > >
> > > --
> > >
> > > ________________________________ 
> > > toddgrimason*todd[ at ]slack.net
> > >
> > >
> > > _______________________________________________
> > > Rails mailing list
> > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org 
> > > http://lists.rubyonrails.org/mailman/listinfo/rails
> > >
> > 
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> > 
> 
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 
> 
>

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

He''s using iterm (iterm.sourceforge.net) as a terminal. This lets you
have tabs.
I think the auto complete stuff is custom macros he''s made. I
don''t
think there included in the basic Textmate.

On 15 Jul 2005, at 13:33, Kieran Johnson wrote:
> I think the auto complete stuff is custom macros he''s made. I
don''t
> think there included in the basic Textmate.
AFIK most, if not all, those snippets, macros and commands is  
available in TextMate, even though you might need to get the full  
Rails/Ruby bundles from the SVN repos.

Even if they were not in the repos, most of them would take seconds  
to create yourself, so if you''re using OS X then give TextMate a real  
try. (only a happy user, and not paid to promote it ;-) )

Kind regards,

Mats

----
"TextMate, coding with an incredible sense of joy and ease"
- www.macromates.com -

Op 15-jul-2005, om 15:44 heeft Mats Persson het volgende geschreven:
>> I think the auto complete stuff is custom macros he''s made. I
>> don''t think there included in the basic Textmate.
>
> AFIK most, if not all, those snippets, macros and commands is  
> available in TextMate, even though you might need to get the full  
> Rails/Ruby bundles from the SVN repos.
No, it''s only available for b5 or something like that. Since, the  
syntax higlighting mechanism changed. David''s kinda "sitting
on" the
new version. :) I wish he would release even the "temp" version he
has.

-- 
Regards, Charles.

> No, it''s only available for b5 or something like that. Since, the
> syntax higlighting mechanism changed. David''s kinda "sitting
on" the
> new version. :) I wish he would release even the "temp" version
he has.
I had to download the rails ones from SVN manually, but they work fine
for me.   There''s just so many great bundles in there.  I just
don''t
have the mental capacity to remember enough shortcuts.

Initially, I thought those nifty expansions were some lag or glitch in
the video...

-- 
rick
http://techno-weenie.net

hm? Thats false. Textmate 1.1 beta 14 comes with all the ruby / rails
goodness using the vastly superior new syntax highlighting engine.

On 7/15/05, Charles M. Gerungan
<charles-y71OEPr+RUyakBO8gow8eQ@public.gmane.org>
wrote:
> Op 15-jul-2005, om 15:44 heeft Mats Persson het volgende geschreven:
> 
> >> I think the auto complete stuff is custom macros he''s
made. I
> >> don''t think there included in the basic Textmate.
> >
> > AFIK most, if not all, those snippets, macros and commands is
> > available in TextMate, even though you might need to get the full
> > Rails/Ruby bundles from the SVN repos.
> 
> No, it''s only available for b5 or something like that. Since, the
> syntax higlighting mechanism changed. David''s kinda "sitting
on" the
> new version. :) I wish he would release even the "temp" version
he has.
> 
> --
> Regards, Charles.
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
Tobi
http://www.snowdevil.ca - Snowboards that don''t suck
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog

Op 15-jul-2005, om 17:46 heeft Tobias Luetke het volgende geschreven:
> hm? Thats false. Textmate 1.1 beta 14 comes with all the ruby / rails
> goodness using the vastly superior new syntax highlighting engine.
Not with David''s syntax highlighting. The new pastel one
doesn''t work
nearly as well as his when working outside.

-- 
Regards, Charles.

The style david uses is called All Hallow''s Eve. Activate it in
combination with Markup Styles, CSS/ Html / JS Specifics, as well as
XML and Basic Settings

On 7/15/05, Charles M. Gerungan
<charles-y71OEPr+RUyakBO8gow8eQ@public.gmane.org>
wrote:
> Op 15-jul-2005, om 17:46 heeft Tobias Luetke het volgende geschreven:
> 
> > hm? Thats false. Textmate 1.1 beta 14 comes with all the ruby / rails
> > goodness using the vastly superior new syntax highlighting engine.
> 
> Not with David''s syntax highlighting. The new pastel one
doesn''t work
> nearly as well as his when working outside.
> 
> --
> Regards, Charles.
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
Tobi
http://www.snowdevil.ca - Snowboards that don''t suck
http://typo.leetsoft.com - Open source weblog engine
http://blog.leetsoft.com - Technical weblog

Thanks everybody, exactly what I needed :-) Code folding here I come!

--Alan

On 15-Jul-05, at 10:03 AM, Tobias Luetke wrote:
> The style david uses is called All Hallow''s Eve. Activate it in
> combination with Markup Styles, CSS/ Html / JS Specifics, as well as
> XML and Basic Settings
>
> On 7/15/05, Charles M. Gerungan
<charles-y71OEPr+RUyakBO8gow8eQ@public.gmane.org> wrote:
>
>> Op 15-jul-2005, om 17:46 heeft Tobias Luetke het volgende geschreven:
>>
>>
>>> hm? Thats false. Textmate 1.1 beta 14 comes with all the ruby /  
>>> rails
>>> goodness using the vastly superior new syntax highlighting engine.
>>>
>>
>> Not with David''s syntax highlighting. The new pastel one
doesn''t work
>> nearly as well as his when working outside.
>>
>> --
>> Regards, Charles.
>>
>> _______________________________________________
>> Rails mailing list
>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>>
>
>
> -- 
> Tobi
> http://www.snowdevil.ca - Snowboards that don''t suck
> http://typo.leetsoft.com - Open source weblog engine
> http://blog.leetsoft.com - Technical weblog
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Hi,

Could anyone point me in the direction of the syntax that he is using
for his keyboard shortcuts?  I am going to try to emulate them as much
as possible using Windows UltraEdit.  I will share with the group if I
am moderately successful.

Thanks,
Tom

On 7/15/05, Alan McLean <alan_mclean-ee4meeAH724@public.gmane.org>
wrote:
> Thanks everybody, exactly what I needed :-) Code folding here I come!
> 
> --Alan
> 
> On 15-Jul-05, at 10:03 AM, Tobias Luetke wrote:
> 
> > The style david uses is called All Hallow''s Eve. Activate it
in
> > combination with Markup Styles, CSS/ Html / JS Specifics, as well as
> > XML and Basic Settings
> >
> > On 7/15/05, Charles M. Gerungan
<charles-y71OEPr+RUyakBO8gow8eQ@public.gmane.org> wrote:
> >
> >> Op 15-jul-2005, om 17:46 heeft Tobias Luetke het volgende
geschreven:
> >>
> >>
> >>> hm? Thats false. Textmate 1.1 beta 14 comes with all the ruby
/
> >>> rails
> >>> goodness using the vastly superior new syntax highlighting
engine.
> >>>
> >>
> >> Not with David''s syntax highlighting. The new pastel one
doesn''t work
> >> nearly as well as his when working outside.
> >>
> >> --
> >> Regards, Charles.
> >>
> >> _______________________________________________
> >> Rails mailing list
> >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> >> http://lists.rubyonrails.org/mailman/listinfo/rails
> >>
> >>
> >
> >
> > --
> > Tobi
> > http://www.snowdevil.ca - Snowboards that don''t suck
> > http://typo.leetsoft.com - Open source weblog engine
> > http://blog.leetsoft.com - Technical weblog
> > _______________________________________________
> > Rails mailing list
> > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Todd Grimason said:
> Looks like a worthy competitor is arriving on the scene (but not all the
> way through the door yet...)
>
> http://www.djangoproject.com/
Well it looks like no one bothered to use this thread to comment on this
new framework, but instead were complaining about or defending Rails.
Anyhow, after my cursory glance I think Django looks pretty nice, and I
suspect there may be a few ideas worth looking at.

Unfortunately I''m not much of a Python programmer, so I don''t
know how
deeply I''ll look into Django, but it probably wouldn''t hurt to
play with
it and at least throw together a simple site to test it out. I''ll
probably
do this sometime in the next few months.

Either way competition and new blood is always a good thing in my opinion.
In fact it would probably do a lot of Railers some good to investigate
Nitro + Og and some of the other Ruby web frameworks. While Rails is nice
and DHH is a supremely skilled marketer, it is always a bad idea to become
too much of a fanboy for any technology (unless it''s Ruby...Ruby
Rocks!!!
;)

Ryan

* Ryan Leavengood [2005-07-15 15:41]:
 
> Either way competition and new blood is always a good thing in my opinion.
No doubt, I think this will help both projects and all the projects not
even born yet...

-- 

________________________________
toddgrimason*todd[ at ]slack.net

This is going to be a very exiting time for sofware folks...I can
feel love in the air :)

On 7/15/05, Todd Grimason <todd-cwT7Wi5Y1r1eoWH0uzbU5w@public.gmane.org>
wrote:
> * Ryan Leavengood [2005-07-15 15:41]:
> 
> > Either way competition and new blood is always a good thing in my
opinion.
> 
> No doubt, I think this will help both projects and all the projects not
> even born yet...
> 
> --
> 
> ________________________________
> toddgrimason*todd[ at ]slack.net
> 
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Ryan Leavengood wrote:
>...
> Unfortunately I''m not much of a Python programmer, so I
don''t know how
> deeply I''ll look into Django, but it probably wouldn''t
hurt to play with
> it and at least throw together a simple site to test it out. I''ll
probably
> do this sometime in the next few months.
This is an interesting opportunity, though.  There appear to be many 
people working with Rails who know little Ruby per se.  I wonder (and 
may try to make time to find out) how easy it is to get going with 
Django without knowing much or any Python.
> 
> Either way competition and new blood is always a good thing in my opinion.
> In fact it would probably do a lot of Railers some good to investigate
> Nitro + Og and some of the other Ruby web frameworks. While Rails is nice
> and DHH is a supremely skilled marketer, it is always a bad idea to become
> too much of a fanboy for any technology (unless it''s Ruby...Ruby
Rocks!!!
> ;)
Indeed, it behooves a serious user of any tool or framework to be 
familiar with the alternatives to avoid mental constipation.  Even if 
you don''t care for what you see, a little roughage is good.

James

Neeraj Kumar wrote:
> I tend to view "truly flexible" by another term: "Make
everything equally hard".
> +1
So, is Ruby not truly flexible?

James

On 15-jul-2005, at 21:48, Cuong Tran wrote:
>  This is going to be a very exiting time for sofware folks...I can
> feel love in the air :)
To me it seems that it''s going to be a tough time for PHP.

-- 
Julian "Julik" Tarkhanov

I tend to view "truly flexible" by another term: "Make everything
equally hard".
+1




On 7/15/05, David Heinemeier Hansson
<david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> > What''s the point in OR mapping if
> > you have to name fields and tables in certain ways to make the map
> > meaningful?
> 
> Your frustration seems like it might be one of mismatched
> expectations. Rails uses the Active Record pattern for ORM, which
> trades freedom of mapping for less software (and configuration). Your
> situation might be calling for a full-fledged data mapper if
you''re
> feeling too much pain bending Active Record. Fowler has a good
> description on the differences in Patterns of Enterprise Application
> Architecture.
> 
> But I don''t know your schema. Maybe it''s not so legacy as
being unable
> for Active Record to bend to. But you seem intent on focusing your
> rant on whether one feature of Rails (the scaffolding generator) will
> bend all the way or not. I bet you could have recreated the code the
> scaffolding generator does for you three times over in the time it
> took you to write this. There are quite a few tutorials out there to
> help you. And even a book now.
> 
> "Without the golden path, Rails would be truly flexible and
powerful".
> Heh. The golden path is also what we call "Convention over
> Configuration". One of the most lauded aspects of Rails. It allows you
> to trade idiosyncrasies for productivity. Learn a handful of
> conventions and you''ll never have to specify their consequences
> explicitly again.
> 
> I tend to view "truly flexible" by another term: "Make
everything equally hard".
> 
> All this being said, Active Record does, as stated above, bend. Lots
> of people have found that it has been easier to bend AR rather than
> switch to a full data mapper. I suggest you give it a try. We have a
> community available here on the mailing list and on the IRC channel to
> help you with specific issues. And there''s the ticket system to
report
> outright breakage.
> 
> Of course, getting help will be much easier if you''re willing to
> accept that you perhaps don''t yet appreciate why all of the design
> choices in Rails came out as they did. If you do, your "hate" for
> "needless dogma", "needless restrictions", and 
"pointless
> limitations" might be replaced by curiosity. Could it be that needless
> in another light is helpful? Could it be that restrictions from a
> different perspective is liberating?
> 
> I believe that if you open your mind the rest will follow.
> 
> Welcome to Rails.
> --
> David Heinemeier Hansson
> http://www.loudthinking.com -- Broadcasting Brain
> http://www.basecamphq.com   -- Online project management
> http://www.backpackit.com   -- Personal information manager
> http://www.rubyonrails.com  -- Web-application framework
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Op 15-jul-2005, om 19:03 heeft Tobias Luetke het volgende geschreven:
> The style david uses is called All Hallow''s Eve. Activate it in
> combination with Markup Styles, CSS/ Html / JS Specifics, as well as
> XML and Basic Settings
They''re kinda pastel-like and not as good outside as the original.  
Anyway, according to Allan it''s not the same and he''s still
waiting
on it...

Anyway, this is not ROR anymore.

-- 
Regards, Charles.

Neeraj Kumar wrote:
> I tend to view "truly flexible" by another term: "Make
everything equally hard".
> +1
+2

I dunno. I don''t think PHP is getting any more difficult or anything.  
I''m curious how you think it''s gonna get tough for PHP coders.



On Jul 15, 2005, at 5:05 PM, Julian ''Julik'' Tarkhanov wrote:
>
> On 15-jul-2005, at 21:48, Cuong Tran wrote:
>
>
>>  This is going to be a very exiting time for sofware folks...I can
>> feel love in the air :)
>>
>
> To me it seems that it''s going to be a tough time for PHP.
>
> -- 
> Julian "Julik" Tarkhanov
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Ryan Leavengood wrote:
> Todd Grimason said:
> 
>>Looks like a worthy competitor is arriving on the scene (but not all the
>>way through the door yet...)
>>
>>http://www.djangoproject.com/
> 
> 
> Well it looks like no one bothered to use this thread to comment on this
> new framework, but instead were complaining about or defending Rails.
> Anyhow, after my cursory glance I think Django looks pretty nice, and I
> suspect there may be a few ideas worth looking at.
> 
> Unfortunately I''m not much of a Python programmer, so I
don''t know how
> deeply I''ll look into Django, but it probably wouldn''t
hurt to play with
> it and at least throw together a simple site to test it out. I''ll
probably
> do this sometime in the next few months.
> 
> Either way competition and new blood is always a good thing in my opinion.
> In fact it would probably do a lot of Railers some good to investigate
> Nitro + Og and some of the other Ruby web frameworks. While Rails is nice
> and DHH is a supremely skilled marketer, it is always a bad idea to become
> too much of a fanboy for any technology (unless it''s Ruby...Ruby
Rocks!!!
> ;)
That''s my take a well. I posted a note about Django on my blog this 
morning asking for comments from Pythonistas who are familiar with 
Rails. I''ve had a few comments posted, hopefully some good stuff will 
follow. You can read it here:

 
http://blog.curthibbs.us/articles/2005/07/15/does-rails-finally-have-a-real-competitor

Curt

There is a reason why there is Rails, and there''s a reason why other  
frameworks start to appear that are modelled like it.

And that reason is not because PHP is wonderful. Or Java/.NET web  
development for that matter. :)

Thomas

Am 15.07.2005 um 23:16 schrieb Toby Boudreaux:
> I dunno. I don''t think PHP is getting any more difficult or  
> anything. I''m curious how you think it''s gonna get tough
for PHP
> coders.
>
>
>
> On Jul 15, 2005, at 5:05 PM, Julian ''Julik'' Tarkhanov
wrote:
>
>
>>
>> On 15-jul-2005, at 21:48, Cuong Tran wrote:
>>
>>
>>
>>>  This is going to be a very exiting time for sofware folks...I can
>>> feel love in the air :)
>>>
>>>
>>
>> To me it seems that it''s going to be a tough time for PHP.
>>
>> -- 
>> Julian "Julik" Tarkhanov
>>
>> _______________________________________________
>> Rails mailing list
>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Sure, there are lots of reasons for Rails and lots of reasons for  
similar frameworks and lots of reasons why there are a few PHP clones  
in development and lots of reasons why relatively old patterns are  
finding their way into Web development and lots of reasons why it''s  
important to maintain a very diverse, yet thorough understanding of  
many relevant technologies.

This still doesn''t mean that things are changing for PHP coders or  
for PHP as a language.

PHP is still a good, popular, powerful language, though admittedly a  
little inconsistent. The ubiquity is not going to change any time  
soon. How are things going to get *tough* for PHP coders? Are they  
gonna lose their jobs? Has Zend given up their efforts and moved into  
the cult of Railsies? Nothing is changing in PHP for the worse.






On Jul 15, 2005, at 5:24 PM, Thomas Fuchs wrote:
> There is a reason why there is Rails, and there''s a reason why  
> other frameworks start to appear that are modelled like it.
>
> And that reason is not because PHP is wonderful. Or Java/.NET web  
> development for that matter. :)
>
> Thomas
>
> Am 15.07.2005 um 23:16 schrieb Toby Boudreaux:
>
>
>> I dunno. I don''t think PHP is getting any more difficult or  
>> anything. I''m curious how you think it''s gonna get
tough for PHP
>> coders.
>>
>>
>>
>> On Jul 15, 2005, at 5:05 PM, Julian ''Julik'' Tarkhanov
wrote:
>>
>>
>>
>>>
>>> On 15-jul-2005, at 21:48, Cuong Tran wrote:
>>>
>>>
>>>
>>>
>>>>  This is going to be a very exiting time for sofware folks...I
can
>>>> feel love in the air :)
>>>>
>>>>
>>>>
>>>
>>> To me it seems that it''s going to be a tough time for PHP.
>>>
>>> -- 
>>> Julian "Julik" Tarkhanov
>>>
>>> _______________________________________________
>>> Rails mailing list
>>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>>
>>>
>>>
>>
>> _______________________________________________
>> Rails mailing list
>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Looks good, Django certainly seems to be focusing on the same stuff Rails is.

One thing that struck me as peculiar is that they seem to subscribe to
the idea that interfaces can and should be generated. Rails uses
scaffolding as temporary code, intended to get you started. Django
makes a point out of having "not just scaffolding, it''s the whole
house", claiming that the admin interface of a webapp can be
"generated". So instead of generating temporary code and interfaces,
like Rails'' scaffolding, they''re generating pretty much the
admin
interface as intended to be used in the long run. (If I''m
misunderstanding their intentions with the generated admin interface,
how is it different from scaffolding?) Seeing as you''re an intelligent
crowd, I''m not going to get into why generating interfaces rarely if
ever is a good idea.
>From what I can tell, it does do some of the things that Rails does,
but the only way I can see how it tries to excel over Rails is by this
auto-generation of admin interfaces, which imho is an anti-feature
(again, I could be misunderstanding them on this point). But even if
it doesn''t even try to excel over Rails in any arena, it still seems
to potentially be a pretty good Python alternative to Rails.

Regards,
Tomas Jogin

On 7/15/05, Todd Grimason <todd-cwT7Wi5Y1r1eoWH0uzbU5w@public.gmane.org>
wrote:
> Looks like a worthy competitor is arriving on the scene (but not all the
> way through the door yet...)
> 
> http://www.djangoproject.com/
> 
> 
> 
> --
> 
> ________________________________
> toddgrimason*todd[ at ]slack.net
> 
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

I don''t think PHP is a "good and powerful" language (I
won''t go into
details as why, others have pointed that out before me[1][2][3]), but  
it is popular, correct.

But: there will be fewer projects done in PHP with the emerging of  
"new ways to do stuff". Such transitions have happened before.

The coders won''t loose their jobs, but clearly the "world of web  
development" is undergoing a turning point right now - so they better  
start to look at whats beyond PHP.

I myself have used PHP quite a lot, and other languages/frameworks  
too; and i''ve seen the light at the end of the tunnel only when I  
came across Rails. To quote Scott Barron on the Rails Podcast: "I was  
about to give up programming until Rails came along".

Time will tell. :)

[1] http://spyced.blogspot.com/2005/06/why-php-sucks.html
[2] http://www.bitstorm.org/edwin/en/php-sucks/
[3] http://n3dst4.com/articles/phpannoyances/

Am 15.07.2005 um 23:33 schrieb Toby Boudreaux:
> PHP is still a good, popular, powerful language, though admittedly  
> a little inconsistent. The ubiquity is not going to change any time  
> soon. How are things going to get *tough* for PHP coders? Are they  
> gonna lose their jobs? Has Zend given up their efforts and moved  
> into the cult of Railsies? Nothing is changing in PHP for the worse.

James Britt wrote:
> Neeraj Kumar wrote:
> 
>> I tend to view "truly flexible" by another term: "Make
everything
>> equally hard".
>> +1
> 
> 
> So, is Ruby not truly flexible?
Yes, it is.  Like all such statements, the interpretation depends on 
context.  :-)

Curt

On 15-jul-2005, at 23:33, Toby Boudreaux wrote:
>
> This still doesn''t mean that things are changing for PHP coders or
> for PHP as a language.
Not as a flamebait - but I think exactly the opposite. After working  
with Rails both PHP and PHP-based solutions seem:
a) clunky
b) dirty
c) downright counterproductive
which might (will and already does) evoke some doubts in people who  
are driving "the new wave" of object-oriented PHP and bending it Java-
style.



-- 
Julian "Julik" Tarkhanov

* Tomas Jogin [2005-07-15 18:12]:
 
> >From what I can tell, it does do some of the things that Rails does,
> but the only way I can see how it tries to excel over Rails is by this
Well, for a lot of people its killer feature will be that it''s written
in Python. I also think "tries to excel over Rails..." is maybe a bit
of projection - they don''t state that as a goal do they?

Another differentiator for some will be that it runs on mod_python which
is by definition apache2. That will rule it in for some, out for others.

BUT, WSGI support is planned which is sort of a uber-foundation for
python web frameworks that will allow it to be deployed via FastCGI, and
a plethora of other options...


-- 

________________________________
toddgrimason*todd[ at ]slack.net

> Well, for a lot of people its killer feature will be that it''s
written
> in Python. I also think "tries to excel over Rails..." is maybe a
bit
> of projection - they don''t state that as a goal do they?
Maybe it''s just me, but they seem to throw a couple of jabs at Rails
in their description of Django. One being that their admin generation
thing is "not just scaffolding". Besides, it was labeled a
"Rails-killer" by Jason Higgins. I think the obvious question is
"how"?

Regards,
Tomas Jogin

Another great thing about TextMate is that it''s getting cheaper for us 
in the US as the currency rates change.  Was ~$59 US a couple months 
ago, now ~$47. :)

Tom Davies wrote:
> Hi,
>
> Could anyone point me in the direction of the syntax that he is using
> for his keyboard shortcuts?  I am going to try to emulate them as much
> as possible using Windows UltraEdit.  I will share with the group if I
> am moderately successful.
>
> Thanks,
> Tom
>
> On 7/15/05, Alan McLean <alan_mclean-ee4meeAH724@public.gmane.org>
wrote:
>   
>> Thanks everybody, exactly what I needed :-) Code folding here I come!
>>
>> --Alan
>>
>> On 15-Jul-05, at 10:03 AM, Tobias Luetke wrote:
>>
>>     
>>> The style david uses is called All Hallow''s Eve. Activate
it in
>>> combination with Markup Styles, CSS/ Html / JS Specifics, as well
as
>>> XML and Basic Settings
>>>
>>> On 7/15/05, Charles M. Gerungan
<charles-y71OEPr+RUyakBO8gow8eQ@public.gmane.org> wrote:
>>>
>>>       
>>>> Op 15-jul-2005, om 17:46 heeft Tobias Luetke het volgende
geschreven:
>>>>
>>>>
>>>>         
>>>>> hm? Thats false. Textmate 1.1 beta 14 comes with all the
ruby /
>>>>> rails
>>>>> goodness using the vastly superior new syntax highlighting
engine.
>>>>>
>>>>>           
>>>> Not with David''s syntax highlighting. The new pastel
one doesn''t work
>>>> nearly as well as his when working outside.
>>>>
>>>> --
>>>> Regards, Charles.
>>>>
>>>> _______________________________________________
>>>> Rails mailing list
>>>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>>>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>>>
>>>>
>>>>         
>>> --
>>> Tobi
>>> http://www.snowdevil.ca - Snowboards that don''t suck
>>> http://typo.leetsoft.com - Open source weblog engine
>>> http://blog.leetsoft.com - Technical weblog
>>> _______________________________________________
>>> Rails mailing list
>>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>>
>>>       
>> _______________________________________________
>> Rails mailing list
>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>>     
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>

> Indeed, it behooves a serious user of any tool or framework to be  
> familiar with the alternatives to avoid mental constipation.  Even if  
> you don''t care for what you see, a little roughage is good.
Agreed.

I actually couldn''t care less about rails scaffolding being anything  
more than it is now, really. I just want something to type a bunch of  
stuff for me so it takes me less time to customize it. Anything that  
claims to generate something fully useable for me is suspect. It''s  
hype, unless there''s a nice AI sitting in there that you can talk to so
it understands how you''d like to interfaces, thanks ;P

Anyway: django _does_ have one thing over rails which I like, which I''m
sure others won''t: a proper template system.

They appear to have copied smarty - which I think is great, I always  
did like smarty. It''s possibly the most functional basic tool  
implemented for PHP. binarycloud relies on smarty for all node  
templates and it works freaking well.

I dislike what I consider to be ugly aspish tags in rails: <%= stuff  
%>. {{ something|modifier }} is really cool and convenient, IMHO. Their  
uri mapping stuff isn''t anything like as cool as rails, map.connect  
whips the llama''s ass.

mod_python is crap, but that''s not their fault. The sites they point to
do actually work and are well designed, etc. but there''s nothing that  
is making me cream my panties.

There is a comment here:

http://blog.curthibbs.us/articles/2005/07/15/does-rails-finally-have-a- 
real-competitor

Which notes the other major difference I saw immediately: they take the  
binarycloudish (sorry, I see through that lens) idea of a fully scale  
free hierarchy of templates which are assembled from a tree of objects  
into a single object which is returned to the client. It''s cool, but  
frankly in 99.99999% of cases it''s overkill and it just gets in the  
way. At least, as the designer of that system, that''s the conclusion I
came to. I''ve used it a lot on big sites, and I usually ended up just  
passing in gigantic arrays with everything I wanted on a page into a  
template, and writing neato little smarty includes which knew how to  
display their part of the array.

Django looks very nice. I probably won''t switch.

So:
	-maybe consider a tpl system for rails
	-DEFINITELY consider more sophisticated standard form tools for rails

It''s always very interesting to look at other people''s ideas.
Not all
of them will be perfect, rails is certainly far from perfect, since  
perfection is a question of the specific application. But rails is  
excellent, and Django seems to be very well thought out, perhaps not  
quite as clean as rails and missing some of its features. Rails has the  
cleanest basic framework design I have seen.

So let''s all have a look at it, see if there are any good ideas, and  
take them, and make them better ;) In time I''m sure Django will keep  
getting better, but I prefer ruby.

Hey, at least it isn''t some java bullshit claiming to be a rails  
killer...

;)

_a


-- 
alex black, founder
the turing studio, inc.

510.666.0074
root-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org
http://www.turingstudio.com

2600 10th street, suite 635
berkeley, ca 94710

Why does everything have to be a "killer" It''s like
"iPod-killer"...

When will people stop basing business models on killing a good and  
powerful product with a large market share from a responsive and in  
most cases pro-active company?

Python people use Django. Ruby people use Rails. People who don''t  
know either try em both out.

On Jul 15, 2005, at 6:55 PM, Tomas Jogin wrote:
> Besides, it was labeled a
> "Rails-killer" by Jason Higgins.
--

John Athayde
bobo-8WfjrGkLNeNByuSxxbvQtw@public.gmane.org

Meticulous | www.meticulous.com (work)
Rotoscope | www.rotoscope.com (sound: rock band)
Boboroshi & Kynz | www.boboroshiandkynz.com (sound: electronic)
Personal Weblog | www.boboroshi.com (play)

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
          - Benjamin Franklin (1706-1790)
                        Reply of the Pennsylvania Assembly to the  
Governor
                                  November 11, 1755



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

someone needs to release a hype-killer

-- 

________________________________
toddgrimason*todd[ at ]slack.net

On Fri, 2005-07-15 at 17:01 -0700, alex black wrote:
> Anyway: django _does_ have one thing over rails which I like, which
I''m
> sure others won''t: a proper template system.
Well, one potential added benefit for me (and I''m not sure if this is
true, given the mention of mod_python) is that django, being python, could
potentially run via Jython, which means you should be able to shoehorn it
in to a Java servlet container.

Why do I care?  Because it would make it so much easier for us to deploy
on a large scale (we''re already a Java shop) and it really increases
integration possibilities.

I only wish JRuby were further along... <sigh/> :)

John

On Fri, Jul 15, 2005 at 05:33:37PM -0400, Toby Boudreaux
wrote:
> Sure, there are lots of reasons for Rails and lots of reasons for  
> similar frameworks and lots of reasons why there are a few PHP clones  
> in development and lots of reasons why relatively old patterns are  
> finding their way into Web development and lots of reasons why
it''s
> important to maintain a very diverse, yet thorough understanding of  
> many relevant technologies.
IMHO the most important reason is that nobody''s figured out how to do
(server-side) web technology right. Even "MVC" as it was originally
intended (though a good step), is a difficult fit with the request /
response technology that is HTTP. I''m pretty sure that MVC is not going
to be the last word in web-based application design.

(I hear a lot of good things about WebObjects too lately, I''m not sure
if it fits HTTP any better than MVC. If anyone has some pointers to
a good architectural overview of WebObjects - or any other strategy / 
pattern / architecture - please reply.)
> This still doesn''t mean that things are changing for PHP coders or
> for PHP as a language.
> 
> PHP is still a good, popular, powerful language, though admittedly a  
> little inconsistent. The ubiquity is not going to change any time  
> soon. How are things going to get *tough* for PHP coders? Are they  
> gonna lose their jobs? Has Zend given up their efforts and moved into  
> the cult of Railsies? Nothing is changing in PHP for the worse.
I dislike PHP for estethic reasons. If you''re prepared to put up with
the uglyness of it, it''s quite an efficient language to code webbased
programs in. If people want to code in PHP, then that''s their concern,
as long as I don''t have to, I don''t care about it.


By the way: about a year ago I wrote an article for perlmonks.org about
on MVC for the web. I''ve put a slightly updated version here:

http://zeekat.nl/joost/mvc-web/index.html

There are some parts I would have put differently now, but if you want
to see where I''m coming from, it might be interesting.

Cheers,
Joost.

One thing nobody seems to have commented on is that Django seems to
generate the database (rather than how Rails does it), based on
defined classes in .py files. What happens when I decide I need to
change something in one of my classes? Does it drop the entire
table/database and start again (losing all data in the process)?


--John

On Saturday 16 July 2005 03:36, Joost Diepenmaat wrote:
> (I hear a lot of good things about WebObjects too lately, I''m not
> sure if it fits HTTP any better than MVC.
WebObjects is MVC. The current use of MVC related to web apps stems from 
NeXtStep/OpenStep (ancestors of Mac OS X), not the original Smalltalk 
MVC-flavor. WebObjects was, more or less, NeXt''s attempt at bringing 
that programming model to the web.
> If anyone has some pointers 
> to a good architectural overview of WebObjects - or any other
> strategy / pattern / architecture - please reply.)
http://developer.apple.com/referencelibrary/GettingStarted/GS_WebObjects/index.html

Michael

-- 
Michael Schuerig                          Thinking is trying to make up
mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org                for a gap
in one''s education.
http://www.schuerig.de/michael/                          --Gilbert Ryle

> I''m pretty sure that MVC is not going
> to be the last word in web-based application design.
Yeah. I agree. So do a few others. Try the tutorial here and
experience the love:

http://seaside.st/

And Tapestry (http://jakarta.apache.org/tapestry) is a WebObjects- 
like open-source framework.  It has some very compelling features  
such as true reusable web componentry and a tight integration with  
JavaScript.  The AJAX goodness has not extended deep into the  
framework yet, but it is primed and ready for it (and there are some  
AJAX-enabled components already out there).  Tapestry''s templates are  
"pure" HTML.  Components bind to an object graph and when forms are  
submitted the parameters become directly bound back into the objects  
seamlessly.

I personally think Rails templating could benefit from these sorts of  
ideas, though it does add a substantial amount of complexity under  
the covers of the framework.  In Tapestry, templates are essentially  
first class citizens and objects unto themselves.  In Ruby,  
everything is an "object" - why not templates in Rails?  :)

     Erik


On Jul 16, 2005, at 4:02 AM, Michael Schuerig wrote:
> On Saturday 16 July 2005 03:36, Joost Diepenmaat wrote:
>
>> (I hear a lot of good things about WebObjects too lately, I''m
not
>> sure if it fits HTTP any better than MVC.
>>
>
> WebObjects is MVC. The current use of MVC related to web apps stems  
> from
> NeXtStep/OpenStep (ancestors of Mac OS X), not the original Smalltalk
> MVC-flavor. WebObjects was, more or less, NeXt''s attempt at
bringing
> that programming model to the web.
>
>
>> If anyone has some pointers
>> to a good architectural overview of WebObjects - or any other
>> strategy / pattern / architecture - please reply.)
>>
>
> http://developer.apple.com/referencelibrary/GettingStarted/ 
> GS_WebObjects/index.html
>
> Michael
>
> -- 
> Michael Schuerig                          Thinking is trying to  
> make up
> mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org                for a
gap in one''s
> education.
> http://www.schuerig.de/michael/                          --Gilbert  
> Ryle
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 7/16/05, Erik Hatcher
<erik-LIifS8st6VgJvtFkdXX2HpqQE7yCjDx5@public.gmane.org>
wrote:
> I personally think Rails templating could benefit from these sorts of
> ideas, though it does add a substantial amount of complexity under
> the covers of the framework.  In Tapestry, templates are essentially
> first class citizens and objects unto themselves.  In Ruby,
> everything is an "object" - why not templates in Rails?  :)
Personally, one of the enticing points about Rails for me is the
simplicity of the RHTML views. I like being able to work with the raw
HTML rather than abstractions, and insert a little presentation-geared
Ruby code into the page when it makes sense. It makes for much more
straightforward, easier solutions.

By day I''m an ASP.NET developer, and due to the strict seperation of
code/presentation in the ASP.NET templates I find myself needing to
code a lot more to achieve simple tasks in a template. If I were able
to easily intersperse some code life would be a lot easier.

Tapestry and ASP.NET templates look very nice in theory, but in
practice they don''t always work quite that well.

Ben

On Jul 16, 2005, at 7:08 AM, Ben Myles wrote:
> On 7/16/05, Erik Hatcher
<erik-LIifS8st6VgJvtFkdXX2HpqQE7yCjDx5@public.gmane.org> wrote:
>
>> I personally think Rails templating could benefit from these sorts of
>> ideas, though it does add a substantial amount of complexity under
>> the covers of the framework.  In Tapestry, templates are essentially
>> first class citizens and objects unto themselves.  In Ruby,
>> everything is an "object" - why not templates in Rails?  :)
>>
>
> Personally, one of the enticing points about Rails for me is the
> simplicity of the RHTML views. I like being able to work with the raw
> HTML rather than abstractions, and insert a little presentation-geared
> Ruby code into the page when it makes sense. It makes for much more
> straightforward, easier solutions.
>
> By day I''m an ASP.NET developer, and due to the strict seperation
of
> code/presentation in the ASP.NET templates I find myself needing to
> code a lot more to achieve simple tasks in a template. If I were able
> to easily intersperse some code life would be a lot easier.
>
> Tapestry and ASP.NET templates look very nice in theory, but in
> practice they don''t always work quite that well.
And to be somewhat contradictory with my own comments, I concur with  
what you''ve said.  I have fought against Tapestry to accomplish some  
simple things.  On the other hand, I''ve also been able to accomplish  
very complex things easily that would be difficult to do any a pure  
JSP/RHTML fashion.

I''m relatively pleased with Rails templating at the moment, but  
having experienced the joys of WebObjects and Tapestry I still see  
room for borrowing some of their ideas.

     Erik

On Saturday 16 July 2005 12:40, Erik Hatcher wrote:
> And Tapestry (http://jakarta.apache.org/tapestry) is a WebObjects-
> like open-source framework.  It has some very compelling features
> such as true reusable web componentry and a tight integration with
> JavaScript.  The AJAX goodness has not extended deep into the
> framework yet, but it is primed and ready for it (and there are some
> AJAX-enabled components already out there).  Tapestry''s templates
are
> "pure" HTML.  Components bind to an object graph and when forms
are
> submitted the parameters become directly bound back into the objects
> seamlessly.
I''ve worked professionally with WebObjects for about 15 months;
Tapestry
I only know from the couple of chapters I read in "Tapestry in 
Action" (when, sort of by historical accident, it got trumped by 
Rails). Both a very nice, no doubt. If I had to work in Java right now 
I''d use a combination of Spring and Tapestry, if I could.

From a software engineering point of view, the component-based UI 
offered by WebObjects and Tapestry is much more impressive than ERB. On 
the surface, ERB seems to resemble JSP with all its drawbacks, low 
abstraction level in particular. To my own surprise, this doesn''t hold 
true in practice. One reason is that the embedded language is Ruby, not 
some retarded mini-languages as in JSP. The main reason, in my 
experience is that Rails makes abstraction easy with helper methods and 
partials.
> I personally think Rails templating could benefit from these sorts of
> ideas, though it does add a substantial amount of complexity under
> the covers of the framework.  In Tapestry, templates are essentially
> first class citizens and objects unto themselves.  In Ruby,
> everything is an "object" - why not templates in Rails?  :)
I, too, would be interested in a component-based web UI framework for 
use with Rails. However, I do not automatically expect it to be better 
than what we currently have.

Michael

-- 
Michael Schuerig                            This is not a false alarm
mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org                        
This is not a test
http://www.schuerig.de/michael/                      --Rush, Red Tide

Good and powerful seem indisputable to me. I didn''t say "great and
perfect" on purpose. There are many problems with PHP as a language.  
That doesn''t mean that it isn''t powerful, or that it
isn''t good.

I agree that the state of tech is in flux - hell, it''s ALWAYS in flux.

You mention that people need to "start to look at what''s beyond
PHP"
and I think that puts this entire sub-thread into perspective for me.

I agree that anyone, anywhere, with a devotion to a single language  
or framework is a person with a tough world in front of them. I  
wouldn''t hire anyone who couldn''t comfortably and without
bitching
and moaning jump into at least 80% of client projects with an  
agnostic attitude and with grace.

Fanboys/girls and hobbyists are certainly not the folks I''m thinking
of.

I''m used to working in a shop environment, though, where you have to  
be proficient in at least 3 major languages and not *require* any  
frameworks to consistently get your job done. Good coding can be done  
in any language I''ve ever seen. Sometimes it''s just hard to
find good
coders.

The world of PHP does have a pretty large proportion of hacks and cut- 
n-pasters, of people who know PHP and only PHP. (Those folks are  
screwed no matter what alternatives are out there. If the RoR crowd  
wants to woo them, please do!) Most frameworks for PHP aren''t very  
good, to say the least. Smarty is a plague. I''m sure that it''s
preaching to the wrong folks here to suggest that it''s more than  
possible for some coders to personally develop the most productive  
set of practices for themselves given their most common needs and  
workflows. Not having done something doesn''t mean it''s
impossible, it
just means you didn''t succeed. When I work on a PHP4 project, I have  
a certain methodology, certain trusted and proven packages I''ve  
written over the years. It''s the same with PHP5 and Python. Some pull  
from the work of others, some are entirely my own. They''re all  
consistent and follow what I feel is the best approach for the  
project at hand.

No framework, no language, is perfect. If you run around trying to  
force any one thing on all jobs, you''re likely doing a disservice to  
clients, your shop, and your employees. There is a place for cultish  
unquestioning devotion -- Hollywood.

PHP has a place right now and it''s done a hell of a lot. It
isn''t
going away and it''s certainly not in trouble, in my view.

I''m not making any claims that it''s perfect or that it
isn''t going to
change in a lot of ways with V6. As is, it''s in high demand and  
that''s why it''s important. I doubt Ruby is gonna take the
market by
storm any time soon. If it happens, there still won''t be an excuse  
for coders banging away at the nails of the world with their single  
hammer.

The links you gave don''t point out anything that is a showstopper for  
me (or thousands of others). Many of the points in those are either  
outdated, purely subjective, or not applicable to *most* uses. One  
complaint listed is that PHP is changing for the better and that  
major-version language updates breaks legacy code. Sounds to me like  
someone doesn''t want to take responsibility for researching their  
updates ;). It''s a silly argument.

Believe me, though - I''m no PHP apologist. I just like to actually  
follow those buzzwords "pragmatic" and "agile" and maintain
an open
mind about tech. The biggest gripe I have with PHP isn''t listed in  
your links: the Unicode support sucks hard. But yeah, I digress. This  
isn''t a discussion that fits on this list.

The original point I was questioning has yet to be addressed. This  
isn''t about whether PHP sucks or whether we should pray for a Ruby  
hegemony. I was wondering how, by virtue of two frameworks (Rails and  
Django) being released, PHP and people who use PHP are in trouble. I  
don''t see a relation, unless the aforementioned hegemonic hold by  
Ruby occurs. Even then, only the people who *only* use PHP are in  
trouble. But, like all staunch single-language culties, they were in  
trouble the day they first sat down to a machine.


On Jul 15, 2005, at 6:17 PM, Thomas Fuchs wrote:
> I don''t think PHP is a "good and powerful" language (I
won''t go
> into details as why, others have pointed that out before me[1][2] 
> [3]), but it is popular, correct.
>
> But: there will be fewer projects done in PHP with the emerging of  
> "new ways to do stuff". Such transitions have happened before.
>
> The coders won''t loose their jobs, but clearly the "world of
web
> development" is undergoing a turning point right now - so they  
> better start to look at whats beyond PHP.
>
> I myself have used PHP quite a lot, and other languages/frameworks  
> too; and i''ve seen the light at the end of the tunnel only when I
> came across Rails. To quote Scott Barron on the Rails Podcast: "I  
> was about to give up programming until Rails came along".
>
> Time will tell. :)
>
> [1] http://spyced.blogspot.com/2005/06/why-php-sucks.html
> [2] http://www.bitstorm.org/edwin/en/php-sucks/
> [3] http://n3dst4.com/articles/phpannoyances/
>
> Am 15.07.2005 um 23:33 schrieb Toby Boudreaux:
>
>
>> PHP is still a good, popular, powerful language, though admittedly  
>> a little inconsistent. The ubiquity is not going to change any  
>> time soon. How are things going to get *tough* for PHP coders? Are  
>> they gonna lose their jobs? Has Zend given up their efforts and  
>> moved into the cult of Railsies? Nothing is changing in PHP for  
>> the worse.
>>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Am 16.07.2005 um 16:23 schrieb Toby Boudreaux:
> I''m used to working in a shop environment, though, where you have
> to be proficient in at least 3 major languages and not *require*  
> any frameworks to consistently get your job done. Good coding can  
> be done in any language I''ve ever seen. Sometimes it''s
just hard to
> find good coders.
Think about why you''ve to be proficient in 3 major languages and  
everyone is reinventing the wheel permanently with their own custom  
frameworks; even if web applications and web sites work basically the  
same way...

I really like the way Rails grew out of the real-life project of a  
"current day" web application; with Ruby as it''s backing.
It''s just
perfect for what i need. No PHP, J2EE, ASP, ASP.NET or whatever could  
do that. Yes, I''m enthusiastic about it. :)

I think some enthusiasm about how you personally like things to be is  
not a bad thing. :) I find it invaluable to have a team of "devoted"  
people, both to the way they work and the project they work on. I''ve  
yet to find people that feel the same way about PHP.

That''s much along the same lines as being an Mac user or a DELL user.  
If I use a tool for 8-12 hours a day, I want it to a) work perfectly,  
b) do what i want and doesn''t stand in the way of this and c) look  
nice. Same thing with programming languages and frameworks, they''re  
just tools too.

The difficult thing is finding the tools that work best for you and  
for what you do.
> Believe me, though - I''m no PHP apologist. I just like to actually
> follow those buzzwords "pragmatic" and "agile" and
maintain an open
> mind about tech. The biggest gripe I have with PHP isn''t listed in
> your links: the Unicode support sucks hard. But yeah, I digress.  
> This isn''t a discussion that fits on this list.
That''s a funny thing about Ruby, too, Unicode support basically sucks  
(it''s even funnier that it originated in Japan, so it should have  
good support for i18n). I hope that will get better when Ruby 2 arrives.


Thomas

On Jul 16, 2005, at 10:57 AM, Thomas Fuchs wrote:
> Think about why you''ve to be proficient in 3 major languages and  
> everyone is reinventing the wheel permanently with their own custom  
> frameworks; even if web applications and web sites work basically  
> the same way...
>
Again - I work in a shop environment, mostly doing work for ad  
agencies or content providers with very strict requirements on their  
projects. The luxury of being able to choose my language, my RDBMS,  
my frameworks, is something that isn''t always a fact. If I were  
running a startup  I''d certainly choose wisely and Ruby/Rails would  
be a contender (depending on the needs, of course).
As for reinventing the wheel, I think you might be making an  
assumption that isn''t really reliable. At least for me and my shop,  
it isn''t the case.

> I really like the way Rails grew out of the real-life project of a  
> "current day" web application; with Ruby as it''s
backing. It''s just
> perfect for what i need. No PHP, J2EE, ASP, ASP.NET or whatever  
> could do that. Yes, I''m enthusiastic about it. :)
>
No PHP, J2EE, etc, could do what? Spawn a framework out of a web app?  
That''s certainly not true.
> I think some enthusiasm about how you personally like things to be  
> is not a bad thing. :) I find it invaluable to have a team of  
> "devoted" people, both to the way they work and the project they
> work on. I''ve yet to find people that feel the same way about PHP.
>
Most definitely. Enthusiasm is great. It just can''t lead to bad (or  
missing) discovery and evaluation when making choices. I find that I  
can be quite enthusiastic about solving problems, no matter which  
tool I''m using -- and the choice isn''t always mine.

There is a space for all languages and again, great work can be done  
in any language if a coder is creative and clever.

I''m quite fond of Rails, but it has limitations and isn''t some
manna
from heaven. It''s fitting QUITE well into the project I''m
currently
working on and it''s a blast to use. I''d love to see the Rails
model
expanded to allow more flexibility then be ported solidly to all  
popular languages.

For those of us working on legacy apps and legacy systems with no  
Ruby interpreter, the conventions pushed in the Rails framework  
aren''t necessarily as great as for folks running a startup or working  
on a small closed project. They become just another quirky ruleset  
that apply only in the small percentage of projects that can be done  
in Rails. An effort to push those conventions into other languages  
would do far more good than trying to get the Ruby interpreter  
installed on more systems. It''s the ideas of Rails that are most  
useful. Conventions are much better when they extend across the  
palette of a high-pressure shop dealing with tons of clients with  
disparate systems.

This is why I think Django might be an amazing tool... it helps  
extend some of the concepts into another amazing language and into  
another chunk of my clients'' servers.





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

> I''m used to working in a shop environment, though, where you have
to
> be proficient in at least 3 major languages and not *require* any
> frameworks to consistently get your job done. Good coding can be done
> in any language I''ve ever seen. Sometimes it''s just hard
to find good
> coders.
Maybe because the good coders aren''t content with working with bad or
suboptimal tools? Maybe, the good coders are the ones passionate about
what they do, and really don''t like to wrestle with bad or weak
languages or frameworks? Maybe wetting one''s pants at the very
possibility of coding for a living, in any language or platform, is
not the sign of a particularly good coder?

Regards,
Tomas Jogin

I''m sure that''s it.

On Jul 16, 2005, at 12:42 PM, Tomas Jogin wrote:
>> I''m used to working in a shop environment, though, where you
have to
>> be proficient in at least 3 major languages and not *require* any
>> frameworks to consistently get your job done. Good coding can be done
>> in any language I''ve ever seen. Sometimes it''s just
hard to find good
>> coders.
>>
>
> Maybe because the good coders aren''t content with working with bad
or
> suboptimal tools? Maybe, the good coders are the ones passionate about
> what they do, and really don''t like to wrestle with bad or weak
> languages or frameworks? Maybe wetting one''s pants at the very
> possibility of coding for a living, in any language or platform, is
> not the sign of a particularly good coder?
>
> Regards,
> Tomas Jogin
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

*lol* interesting discussion. but i can see the problem, i  
experienced exactly the same thing at my old company: legacy apps and  
tools which are not going away until something _very bad_ happens.  
also business interests and "stragetic" decisions and parthnerships  
often give the technical aspects 2nd rank.

over time, all the good coders and the "technically knowledgable  
people" have left the company and moved on to new ventures.
In other words, the company lost the most precious resource a  
software company has: people.

well, life goes on :)

Thomas

Am 16.07.2005 um 18:42 schrieb Tomas Jogin:
>> I''m used to working in a shop environment, though, where you
have to
>> be proficient in at least 3 major languages and not *require* any
>> frameworks to consistently get your job done. Good coding can be done
>> in any language I''ve ever seen. Sometimes it''s just
hard to find good
>> coders.
>>
>
> Maybe because the good coders aren''t content with working with bad
or
> suboptimal tools? Maybe, the good coders are the ones passionate about
> what they do, and really don''t like to wrestle with bad or weak
> languages or frameworks? Maybe wetting one''s pants at the very
> possibility of coding for a living, in any language or platform, is
> not the sign of a particularly good coder?
>
> Regards,
> Tomas Jogin
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Alex I agree with you. I love rails, but I know we can do better when
it comes to the templating.

I''ve been looking at what rails offers, and considering the
benefits/negatives of tapestry, JSF, html templating, etc. I think
that we''ll be able to evolve amrita2 a bit to provide another strong
option to the plate. You''ll always be able to use the rhtml <%=
%>
stuff if you want to, but I hope that we''ll have a cleaner and just as
easy html template option with an enhanced amrita2, complete with
conditional rendering (like jsf), and partials/layouts (but maybe more
similar to tapestry on those regards).

And yes I have read much of the reasons for which DHH and rails chose
the rhtml approach rather than html temlating, but I still believe
that in the future we''ll have another strong viable option if we
address some of the shortcomings of the existing template solutions.
Taku has done some wonderful things in Amrita2 and with a little more
work, I think we can have another first class rails templating
solution that finishes out the rails offering more completely. As time
permits I am looking into how I can help Taku evolve Amrita2
accordingly.

On 7/15/05, alex black <enigma-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org>
wrote:
> I dislike what I consider to be ugly aspish tags in rails: <%= stuff
> %>. {{ something|modifier }} is really cool and convenient, IMHO.

> Alex I agree with you. I love rails, but I know we can do better when
> it comes to the templating.
What limitations or problems have you run into when working with
Rails'' template system?

Regards,
Tomas Jogin

On Sat, 2005-07-16 at 06:40 -0400, Erik Hatcher wrote:
> I personally think Rails templating could benefit from these sorts of  
> ideas, though it does add a substantial amount of complexity under  
> the covers of the framework.  In Tapestry, templates are essentially  
> first class citizens and objects unto themselves.  In Ruby,  
> everything is an "object" - why not templates in Rails?  :)
Yes just so long as I don''t have to:

	* Edit 5 files to get one thing working.
	* Have to leave around empty Blah.page files just so Railsestry will
load my Blah.html and think it''s a page. 
	* Or have to write get/set methods for my looping variables every time
I need to just loop over a collection.
	* Or have to tell Railsestry that, yes, Blah.page, Blah.html, and
com.mystuff.app.BlahPage are all related.
	* Or, have to make a special Visit class with a get/set method for
every possible thing I plan to use through the entire application as a
state variable (I''ve seen some with 50 variables).  I got so frustrated
with the Visit that I just use a HashMap and say "screw it".
	* And please don''t make me write huge ass <span> tags just to
write
"HI".
	* And pretty please, don''t make me put my javascript in special script
XML files in a special place, and configure them in another place, just
so that Railsestry can load them and process them with lots of extra
overhead and inject them into the HTML HEAD so that it can avoid having
to deal with shell components correctly.  Nothing''s more efficient than
having my Java application load JavaScript for the web browser.

Tapestry suffers from the same "configuration madness" that many other
Java project suffer from.  What''s worse is Tapestry doesn''t
need to do
this, but Howard hasn''t figured out that people don''t like
editing 10
files to do one thing.

Anyway, my 0.02 on Tapestry.  I love it when I do Java web apps, but
hate it when I have to edit a billion files to repeat information it
should be able to deduce from convention.

Zed Shaw

Say I have a layout looking like:

<html>
  <head>
    <title>A title</title>
    <script src="javascripts/something"></script>
  </head>
  <body>
    <div id="rightNav"><%= render_partial ...
%></div>
    <%= @content_for_layout %>
  </body>
</html> 

That''s fine.

Say I want to do the exact same although I need each and every page (or
just a couple of them) to include a different javascript file (or css
for that matter). And I want it to go inside the <head/> element. How do
I do that? Haven''t found an answer in the RoR book so if someone could
tell me I would be me more than happy :)

Say I want two areas (or three or four) on the page to be specific for
each page in a sort of complex layout. How would I do that using the
current layout system? I''m not criticizing or anything, I just
don''t
know how to do it and I''m going to need it.

I think perhaps it would be possible to set variables in the controller
that I can use to do render_partial (or render perhaps). But then I have
view logic in my controller and that wouldn''t be so nice, would it?

/Marcus

-----Original Message-----
From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
[mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On
Behalf Of Tomas Jogin
Sent: den 16 juli 2005 19:19
To: Jeff Barczewski; rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails] Re: let the battle begin: Django
> Alex I agree with you. I love rails, but I know we can do better when 
> it comes to the templating.
What limitations or problems have you run into when working with Rails''
template system?

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

http://api.rubyonrails.com/classes/ActionView/Helpers/CaptureHelper.html#M000414




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

Thanks. Solves most problems I think :)

/Marcus 

-----Original Message-----
From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
[mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On
Behalf Of Sean T Allen
Sent: den 16 juli 2005 20:22
To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails] Re: let the battle begin: Django

http://api.rubyonrails.com/classes/ActionView/Helpers/CaptureHelper.html
#M000414

> One thing nobody seems to have commented on is that Django seems to
> generate the database (rather than how Rails does it), based on
> defined classes in .py files. What happens when I decide I need to
> change something in one of my classes? Does it drop the entire
> table/database and start again (losing all data in the process)?
Um, probably not. These _are_ professionals ;)

I suspect it does what metabase does: tells you what to do manually if it
can''t do it automatically. For example, on most DBs simply running
ALTER
TABLE blah to add a new column is totally harmless. Renaming columns is
usually harmless as well. Doing field type changes usually requires
dumping data and reloading it etc.

I actually think well-tested, simple "no magic" SQL generation is a
very,
very nice thing. I''d prefer to see it be part of a command line tool
that
dumps the SQL for you, so you can inspect it and _then_ run it on a DB.

The other nice thing about this is if you''re doing a promote to a
cluster:
you can basically have an update script which also checks for updated to
the DB and runs them automatically for you while it is updating the code,
so you don''t get any scary unpredictable fu in production.

;)

_a

Weblogic presentation sucks as far as I have seen, however their
persistence is some of the most sophisticated, well designed stuff I''ve
seen.

It''s also java, and even with the visual tools - dev is slow and
production isn''t zippy. But the apple store seems to work well, eh? :)

_a
> On Saturday 16 July 2005 03:36, Joost Diepenmaat wrote:
>> (I hear a lot of good things about WebObjects too lately, I''m
not
>> sure if it fits HTTP any better than MVC.
>
> WebObjects is MVC. The current use of MVC related to web apps stems from
> NeXtStep/OpenStep (ancestors of Mac OS X), not the original Smalltalk
> MVC-flavor. WebObjects was, more or less, NeXt''s attempt at
bringing
> that programming model to the web.
>
>> If anyone has some pointers
>> to a good architectural overview of WebObjects - or any other
>> strategy / pattern / architecture - please reply.)
>
>
http://developer.apple.com/referencelibrary/GettingStarted/GS_WebObjects/index.html
>
> Michael
>
> --
> Michael Schuerig                          Thinking is trying to make up
> mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org                for a
gap in one''s education.
> http://www.schuerig.de/michael/                          --Gilbert Ryle
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

> Alex I agree with you. I love rails, but I know we can do better when
> it comes to the templating.
Well, let me be careful and say what I think could be better.

In binarycloud, just like any other framework that uses a separate
template package, you have to do a lot of assignment to "get the data into
the template". That''s dumb:

-typing = bugs. the fewer times I need to type a string, the fewer stupid
typo bugs and bullshit I''ll have to chase down
-as a template author, I want access to everything the system knows at any
given moment. ERB obviously allows that.

So ERB I think is fine, I can get over the <% %> crap. Seaside and
binarycloud both have a way of specifying input sets and forgetting them
so they arre automatically handled. I think that''s excellent, which is
why
I say that sophisticated form tools are missing from rails.

That''s good - at least there isn''t some popular component in
rails for
handling forms that sucks ;)
> benefits/negatives of tapestry, JSF, html templating, etc. I think
> that we''ll be able to evolve amrita2 a bit to provide another
strong
> option to the plate. You''ll always be able to use the rhtml <%=
%>
> stuff if you want to, but I hope that we''ll have a cleaner and
just as
> easy html template option with an enhanced amrita2, complete with
> conditional rendering (like jsf), and partials/layouts (but maybe more
> similar to tapestry on those regards).
Having looked at amrita2, it suffers from the same assignment problems,
though I think worse: you have to construct whole arrays which are tied to
the XHTML DOM you''re working with just to fill in data.

Sure makes it easy for template designers, but I''m a project manager -
and
making one thing easy so it''s a lot harder for another isn''t a
good idea.

I have always always always found that it''s best to preserve the same
simple object structures everythwere - from OR layer right on up to the
template. And if the template needs a little help doing something that
requires complex logic, then it happens in the controller and is made
available to the template.
>From a very quick look at Tapestry presentation, I think it''s
horrible. ;)
It''s a LOT more bullshit to learn just to be able to get access to the
data. I''m much more invavor of really sophisticated tools that are
useable
from ERB.

If we were truly in a world where content was fully separate from data
(and I''be been pretty close) then things would be different - but
speaking
from the real world, I still need a lot of control over every byte of HTML
so I can sidestep bugs, inconsistencies in implementation, things I
can''t
do in CSS while maintaining compatibility with IE, etc.
> Taku has done some wonderful things in Amrita2 and with a little more
> work, I think we can have another first class rails templating
> solution that finishes out the rails offering more completely. As time
> permits I am looking into how I can help Taku evolve Amrita2
> accordingly.
I would be very interested to be involved in that thinking. I think he has
something very good, but I just don''t like what''s necessary to
get the
data into the templates.

But for me, first, it''s form tools ;)

_a

Going through the initial starting tutorial that is now up on the site. 
You create/generate the database by running a command line command,
it''s
not done automatically. They also have a command that will spit out all 
the sql, so you can do as you describe and review/tweak it and then 
manually run it against the DB. Of course depending on the changes you 
make to the SQL you''d have to make sure you then update the model.
I''m
not sure how it handles updates and changes, or if you have to do those 
manually.

--James

alex black wrote:
>Um, probably not. These _are_ professionals ;)
>
>I suspect it does what metabase does: tells you what to do manually if it
>can''t do it automatically. For example, on most DBs simply running
ALTER
>TABLE blah to add a new column is totally harmless. Renaming columns is
>usually harmless as well. Doing field type changes usually requires
>dumping data and reloading it etc.
>
>I actually think well-tested, simple "no magic" SQL generation is
a very,
>very nice thing. I''d prefer to see it be part of a command line
tool that
>dumps the SQL for you, so you can inspect it and _then_ run it on a DB.
>
>The other nice thing about this is if you''re doing a promote to a
cluster:
>you can basically have an update script which also checks for updated to
>the DB and runs them automatically for you while it is updating the code,
>so you don''t get any scary unpredictable fu in production.
>
>;)
>
>_a
>_______________________________________________
>Rails mailing list
>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>
>  
>

>> I''m pretty sure that MVC is not going
>> to be the last word in web-based application design.
Of course not, but that said, I think most of the things rails is
''missing'' have nothing to do with the basic framework design.
The existing
framework is very, very clear and nice, it''s easy to write specs for,
easy
to explain to clients, etc. Most MVC implementations are crap, which is
why, until now, I have not used them.

I went here:

http://seaside.st/Documentation/LinksFormsandCallbacks/

which is pretty good, though I''d like to see how they handle the actual
presentation.

in binarycloud, we handle form elements in similar fashion: every input is
responsible for capturing and self validating its user input. Which means
the actual form class can make a TON of very convenient assumptions about
the data it''s collecting from the object tree instantiated below it.
For
example:

an input can be assigned validation so it runs a regex to ensure that it
contains only A-Z a-z 0-9 . - etc - we were on our way to getting this
hooked up to the model (we called these entities) so we could point an
input at the model validation for the field it was accepting data for.

So the form class which is controlling the whole thing has to worry about
very few things, which makes it simple:

-cross validation between dependent fields
-the mapping, if any, between the inputs in the form and the fields in the
database
-storing the input in the session if the form is ''multi-step''

and a couple other thigns I''ve forgotten.

Revisiting this from a Rails perspective, I think that could be improved
greatly by a concept we had in binarycloud: Models which are simple field
mappings to database tables, and Models which use those simple models to
do other things. (that, or simple allowing for very complex models, which
is OK)

For example, send an email after validating and storing data, or accepting
a set of inputs which are to be processed in soma way before they can be
sent to the simple field model:

you have a simple model which contains a few fields:
    name ( a name)
    color (a hex value, whatever)
    temperature (you always want this number to be in kelvin)

and you want a couple things: a form:

  name (text input)
  color (color select widget)
  temperature (a text input) and (a pulldown with: celsius, fahrenheit,
and kelvin)

and an email to be sent to objects-omLZJFyqO6s4Q++5jOxPmw@public.gmane.org

  name: text input value
  color: color select widget value
  temperature: (float) (kelvin)

You could go one of two ways:
1.  construct a second complex model which knows how to convert from C and
F to K and send email
-or-
2.  make your original model more complex (this may be the better design
decision, I"ve done both)

the example is a bit simplistic, but I think everyone will get the point.

the lack of a common input processing framework in rails is its single
biggest missing piece. it''s what took up the most time in binarycloud,
and
I''m sure we made our fair share of mistakes - but, having put it into
production a few times, it worked (well, works) pretty damn well.

I''d like to see something get written that uses some of the concepts
which
we found to work well in rails. Of course, the techniques would be
slightly different and it would be a tenth the code... but the core idea
is what''s important. _as_much_ introspection as can be done on the
models
to avoid typing field names, the better.

Also, a pet peev: everyone seems to use @flash for error messages - what
ever happened to knowing which input has errors? In binarycluod we
highlighted the field with a problem in addition to providing all of the
error messages at the top of the form. Not that this can''t be done in
rails, but there is no set of guidelines, so everyone just hacks something
up.

In complex applications, many forms are not just a set of fields for
adding or editing a record in a single database table. Handling instances
where your users need to edit something complex (with relationships etc
and maybe over multiple pages) with elegant code and good validation is
the real nut to crack - because everything else is cake by comparison.

;)

_a

> Yeah. I agree. So do a few others. Try the tutorial here and
> experience the love:
>
> http://seaside.st/

> http://seaside.st/Documentation/LinksFormsandCallbacks/
>
> which is pretty good, though I''d like to see how they handle the
actual
> presentation.
I take it back. I read more.

This is the same old mapping crap we have in binarycloud. There are two
instances of the element name in this - I''d like to see something
better... I''d like to type the element name once, in the view, and rest
done with introspection. DRY ;)

_a

Ya, I really thought Tapestry was cool before I met Rails.  Compared  
to struts I thought it was pretty good.  In fact, I would still argue  
that Tapestry is the best Java framework; but Rails is so much slicker.

Thank-you DHH for freeing us from the Java-imposed bondage!

--Dave.

On 16-Jul-05, at 1:24 PM, Zed A. Shaw wrote:
> Yes just so long as I don''t have to:
>
>     * Edit 5 files to get one thing working.
>     * Have to leave around empty Blah.page files just so Railsestry  
> will
> load my Blah.html and think it''s a page.
>     * Or have to write get/set methods for my looping variables  
> every time
> I need to just loop over a collection.
>     * Or have to tell Railsestry that, yes, Blah.page, Blah.html, and
> com.mystuff.app.BlahPage are all related.
>     * Or, have to make a special Visit class with a get/set method for
> every possible thing I plan to use through the entire application as a
> state variable (I''ve seen some with 50 variables).  I got so  
> frustrated
> with the Visit that I just use a HashMap and say "screw it".
>     * And please don''t make me write huge ass <span> tags
just to
> write
> "HI".
>     * And pretty please, don''t make me put my javascript in
special
> script
> XML files in a special place, and configure them in another place,  
> just
> so that Railsestry can load them and process them with lots of extra
> overhead and inject them into the HTML HEAD so that it can avoid  
> having
> to deal with shell components correctly.  Nothing''s more efficient
> than
> having my Java application load JavaScript for the web browser.


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

On Saturday 16 July 2005 21:25, alex black wrote:
> Also, a pet peev: everyone seems to use @flash for error messages -
> what ever happened to knowing which input has errors? In binarycluod
> we highlighted the field with a problem in addition to providing all
> of the error messages at the top of the form. Not that this can''t
be
> done in rails, but there is no set of guidelines, so everyone just
> hacks something up.
Try this for a start
http://wiki.rubyonrails.com/rails/show/HowtoChangeValidationErrorDisplay

Michael

-- 
Michael Schuerig                       All good people read good books
mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org                Now your
conscience is clear
http://www.schuerig.de/michael/ --Tanita Tikaram, Twist In My Sobriety

On 16.7.2005, at 18:15, Toby Boudreaux wrote:
>
> Again - I work in a shop environment, mostly doing work for ad 
> agencies or content providers with very strict requirements on their 
> projects. The luxury of being able to choose my language, my RDBMS, my 
> frameworks, is something that isn''t always a fact.
Do they really insist that you use technology A even if you clearly 
state that you''d be happier and more productive using tool B [1]? If 
so, maybe you should consider hiring the right clients [2]. And yes, I 
know the reality is not always that rosy but I think it''s still worth 
considering—and letting the customers consider.

//jarkko

[1] http://jlaine.net/blog/42/its-about-trust-baby
[2] http://www.37signals.com/svn/archives/001053.php

--
Jarkko Laine
http://jlaine.net
http://odesign.fi


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

Tomas,

The rails rhtml templating system is a good start, but there are
several things which can be improved upon.

First it would be nice to get rid of code in the template where
possible. Code is intermixed with the template to do conditional
logic, to iterate, to generate form fields, and to include partials.
There are cleaner ways to do these sorts of things. And while there
still might be an occasion when it would be necessary I believe that
we can account for many of these things cleanly without needing to
intermix code snippets in the template.

This has many benefits in that the page can be edited, rearranged,
styled, fixed up from within any html editor without fear of messing
anything up. Each client can have their own skin (html template) for
the same app. The pages can be validated against an xhtml/html
validator. One can even start the app from an html prototype and then
continue to use that prototype for the real app.

Also like tapestry the partials and other components could be rendered
using html templates too, so each piece can be validated as valid html
something you can''t do as things are now.

I really dislike putting extra code snippets inside the template to do
things like conditional rendering and iteration. Amrita2 handles
iteration without any extra code, and JSF handles conditional
rendering by simply having an attribute that gets evaluated at
runtime.

But don''t get me wrong, in general rails is several steps above
anything else I have seen, I wouldn''t want to pollute the messiness of
any of the other technologies (tapestry, jsf, etc) into rails, I only
suggest taking some of the better ideas and enhancing rails slightly
to have a first class html templating as well. ERB can still be used
when necessary, but maybe the need for it would be reduced
dramatically.
 

On 7/16/05, Tomas Jogin <tomasj-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> What limitations or problems have you run into when working with
> Rails'' template system?

I think we are all mostly wanting similar things, just different ideas
about how to get there.  It''s all about improving productivity,
maintainability, and having a beautiful work of art once you are done.
Rails and Ruby go a long way towards that goal, I just know that we
can do even a little better.

On 7/16/05, alex black <enigma-16h2cdTTKgpzNNFeSAH1EA@public.gmane.org>
wrote:
> -typing = bugs. the fewer times I need to type a string, the fewer stupid
> typo bugs and bullshit I''ll have to chase down
> -as a template author, I want access to everything the system knows at any
> given moment. ERB obviously allows that.
I agree. I would have a scaffold generator give me the starting html
complete with each and every field accounted for on the pages. Then
one can just simply move things around, hide things, apply style etc.
The system knows the data names so let it spit something out for me to
work with.
> 
> Having looked at amrita2, it suffers from the same assignment problems,
> though I think worse: you have to construct whole arrays which are tied to
> the XHTML DOM you''re working with just to fill in data.
Actually Taku along with some work done by Jamis Buck, has added some
nice funtionality to bridge rails and Amrita2 so that you don''t have
to create arrays or hashes of anything. It can access the data
directly. I think there are still some improvements that can be done
which I am trying to flush out, but alot of it is already in place.

Some of the amrita examples show creating presentation objects to use
for display or also arrays and hashes, but it also supports just
accessing the data directly from the rails objects, no intermediate
structure is required.

I am a big believer in not having to have any intermediate mechanism
too. I want to be able to access anything available and I don''t want
to have to do any extra steps to have access to it.

For me, I would want to be able to do everything as normal in rails
and then simply run a scaffold generator to provide some html to
customize and be done. I think there would be much power in this sort
of simplicity. If it can work like this without needing to add any
additional code to the existing classes (except maybe for edge cases)
then I think it would be pretty powerful.
> 
> From a very quick look at Tapestry presentation, I think it''s
horrible. ;)
> It''s a LOT more bullshit to learn just to be able to get access to
the
> data. I''m much more invavor of really sophisticated tools that are
useable
> from ERB.
>
There is alot to Tapestry, it is pretty complex. There is quite a bit
to learn for what it does. I would only suggest taking a few of the
better ideas from them and leaving the rest.  Having great html
templating goes a long way.
>From there one could think about using components for everything, but
I''m not so sure that there would be as much of a bang for the buck
going that extra mile. It has definite benefits but just getting good
easy html templating would probably satisfy me.

On Jul 16, 2005, at 4:19 PM, Jarkko Laine wrote:
> Do they really insist that you use technology A even if you clearly  
> state that you''d be happier and more productive using tool B [1]?
Yes. Most of the clients for whom I''ve worked have very specific  
design and technology guidelines and teams of highly-skilled in-house  
developers who usually take over maintenance and help with  
integration into any existing systems. These are huge companies with  
lots of high-demand apps and lots of internal red tape and such. Now,  
there have been plenty of times when I''ve been given carte blanche,  
and I''ve used it well -- but it''s never been a rule.


> If so, maybe you should consider hiring the right clients [2]. And  
> yes, I know the reality is not always that rosy but I think it''s  
> still worth considering—and letting the customers consider.

Neither of those links contain much applicable advice for me,  
unfortunately, but thanks! The ideas are certainly good for some  
folks, though. When I consider freelance work, the problems to be  
solved and available toolsets are definitely a consideration. My  
freelance clients aren''t Fortune 500, though ;)

On Sat, 16 Jul 2005, Thomas Fuchs wrote:
> *lol* interesting discussion. but i can see the problem, i experienced
> exactly the same thing at my old company: legacy apps and tools which
> are not going away until something _very bad_ happens.  also business
> interests and "stragetic" decisions and parthnerships often give
the
> technical aspects 2nd rank.
Speaking of legacy apps....

I worked at a company that had one. I think it ran on an old Sinclair (or
something equivalent). Said computer was only used for that one task and
in that one location, so they duct-taped it to the desk (since it was
small enough to walk off with, evidently a couple of people had tried).

Anyhow, one Friday night, some teenagers threw a Molotov cocktail into the
building (same room, but that was a coincidence, really). Burned the
building down.

So I was called in on Saturday to rewrite it as a Mac app, which I did.
Added some features they really wanted on Sunday. By Monday, they were
saving a person-day a week.

-- 
_Deirdre  web / blog: http://deirdre.net/
yarn: http://fuzzyorange.com    cat''s blog: http://fuzzyorange.com/vsd/
"Memes are a hoax! Pass it on!"

On Jul 16, 2005, at 1:24 PM, Zed A. Shaw wrote:
> On Sat, 2005-07-16 at 06:40 -0400, Erik Hatcher wrote:
>
>
>> I personally think Rails templating could benefit from these sorts of
>> ideas, though it does add a substantial amount of complexity under
>> the covers of the framework.  In Tapestry, templates are essentially
>> first class citizens and objects unto themselves.  In Ruby,
>> everything is an "object" - why not templates in Rails?  :)
>>
>
> Yes just so long as I don''t have to:
And don''t forget:

     * Make getters/setters/classes abstract so that the framework  
can automatically wire up state handling.
     * Fight with ugly URL''s making security and web hit tracking  
difficult

(I''m a Tapestry committer, by the way)

But let me annotate some of your comments to clarify Tapestry a bit...
>     * Edit 5 files to get one thing working.
That''s an extreme, and inaccurate IMO, characterization.  Tapestry  
separates things quite well and does a great job at keeping things  
DRY.  In Struts, though, the duplication is enormous - but not so in  
Tapestry.
>     * Have to leave around empty Blah.page files just so Railsestry  
> will
> load my Blah.html and think it''s a page.
I''m pretty sure that it is possible to get away from this, though not  
entirely sure.  I''ve always had a backing .page file, and they
aren''t
empty.
>     * Or have to write get/set methods for my looping variables  
> every time
> I need to just loop over a collection.
A get/set method is unnecessary - a shortcut is to define a <property- 
specification> for the loop variable in the .page file.  I''ve  
disliked even that myself - and would prefer variables to be created  
on the fly and not defined.
>     * Or have to tell Railsestry that, yes, Blah.page, Blah.html, and
> com.mystuff.app.BlahPage are all related.
You''ve never had to declare that the .page/.html are related as it  
determines it automatically by naming conventions (yes, Tapestry has  
a lot of convention over configuration in it too).  The explicit  
tying in of the class is no longer necessary Tapestry 4.0, and in all  
versions I''ve used a base class can be specified once and used as the  
default class when not explicitly overridden.
>     * Or, have to make a special Visit class with a get/set method for
> every possible thing I plan to use through the entire application as a
> state variable (I''ve seen some with 50 variables).  I got so  
> frustrated
> with the Visit that I just use a HashMap and say "screw it".
The default implementation of Visit is a Map - so if you want to be  
loose with it then simply do nothing and you''ve got the Map for free.

The purpose of declaring a rigid Visit class is an important layer  
though - providing an API to the session state rather than it being a  
big loose bucket and having to rely on code standardizing on Map key  
names to get at pieces.  This is an issue that crops up in big apps  
that share state through session scope by key names - developers need  
to keep those key names in sync and it becomes a maintenance  
nightmare to have access to session scattered and loose.   With a  
concrete Visit class, you "benefit" (and that is quoted because in  
this forum it is a "hindrance" instead) from compile-time checking as
well.
>     * And please don''t make me write huge ass <span> tags
just to
> write
> "HI".
This is huge?

     <span jwcid="@Insert" value="ognl:value"/>

and that is the *verbose* form of this:

     <span jwcid="value"/>

On this point you might as well stop now!  :)  We could easily show  
some vastly more uglier (in the eye of the beholder,  
certainly) .rhtml snippets to do something that would look like my  
example.
>     * And pretty please, don''t make me put my javascript in
special
> script
> XML files in a special place, and configure them in another place,  
> just
> so that Railsestry can load them and process them with lots of extra
> overhead and inject them into the HTML HEAD so that it can avoid  
> having
> to deal with shell components correctly.  Nothing''s more efficient
> than
> having my Java application load JavaScript for the web browser.
Nothing in Tapestry makes you do this with JavaScript files.  You can  
easily have static JavaScript and put it into <head> just as you  
would in Rails or plain ol'' static HTML.

Tapestry''s Script component is something I''ve not even
explored that
much myself, and is designed to allow JavaScript to be dynamically  
generated and for parts to be put in <head> if necessary.  Tapestry  
and JavaScript have some sophisticated connections such that  
components can have JavaScript (and assets such as images) come along  
for the ride.  The JavaScript for a component can have pieces  
specific to an instance of a component and a global piece such that  
multiple instances of a component share common functionality.   
The .js that gets served for the global stuff is loaded by the  
browser, not processed by Tapestry.
> Tapestry suffers from the same "configuration madness" that many
other
> Java project suffer from.  What''s worse is Tapestry
doesn''t need to do
> this, but Howard hasn''t figured out that people don''t
like editing 10
> files to do one thing.
You''re given a grossly inaccurate characterization of Tapestry.   
Sure, there are XML configuration files, but they are cleanly  
separated and only come into play when the configuration makes  
sense.  I have presented Tapestry at countless symposiums and I build  
a sophisticated Tapestry application on the fly over the course of  
session from "scratch" (yes, with my IDE and app. server pre- 
configured - so not even close to the Rails trivial initial setup).   
I even am able to change a template or specification file and hit  
refresh in the browser to see the effect of those changes immediately  
(and yes, have to compile to reflect .java changes - but that is only  
a blink of an eye wait).  There is none of the duplication you''re  
complaining about (point me to an example of such, please).  I can  
only presume you''re doing something against the grain of Tapestry and  
implementing unnecessary duplication - nothing that Tapestry is  
forcing upon you.

Tapestry isn''t perfect, and it has parts of it that get on my nerves  
as well, but it is quite elegantly done from a web developers  
perspective in many ways.

I would never suggest that Rails should borrow ugliness from  
anywhere.  We should not close our eyes to good solutions and great  
ideas found elsewhere.  Tapestry and WebObjects both have some ideas  
worth discussing.
> Anyway, my 0.02 on Tapestry.  I love it when I do Java web apps, but
> hate it when I have to edit a billion files to repeat information it
> should be able to deduce from convention.
Again, please point me to where you''ve encountered duplication with  
Tapestry - that simply is not the case in my experience as a web  
developer who has built several applications in production with  
Tapestry and also serves as a (not so active) committer on the project.

     Erik

On 15 Jul 2005, at 23:11, Tomas Jogin wrote:
> One thing that struck me as peculiar is that they seem to subscribe to
> the idea that interfaces can and should be generated. Rails uses
> scaffolding as temporary code, intended to get you started. Django
> makes a point out of having "not just scaffolding, it''s the
whole
> house", claiming that the admin interface of a webapp can be
> "generated". So instead of generating temporary code and
interfaces,
> like Rails'' scaffolding, they''re generating pretty much
the admin
> interface as intended to be used in the long run. (If I''m
> misunderstanding their intentions with the generated admin interface,
> how is it different from scaffolding?) Seeing as you''re an
intelligent
> crowd, I''m not going to get into why generating interfaces rarely
if
> ever is a good idea.
Hi,

Quick disclaimer: I worked on the framework that has now been open- 
sourced as Django for nearly a year, but since leaving the Journal- 
World (where it was written) I haven''t touched the code at all, and I  
wasn''t involved in the open-source release. I''m just now
getting back
up to speed on it.

There''s a very good reason that Django focuses on the automatic  
generation of admin interfaces: Django has a strong focus on content  
management. At the Journal-World we built literally dozens of  
database applications, managing data on everything from sports scores  
to obituaries via blogs, polls, news stories, photo galleries and so  
on. When I left the company our applications used over 200 different  
database tables! Hand coding interfaces for all of those just wasn''t  
viable - especially with only two developers.

Remember, Django''s admin stuff isn''t meant to be used by
members of
the public - it''s designed to be used by the small number of
"staff"
who update the site. You are encouraged to hand-craft the forms that  
the public get to see. You can over-ride Django''s admin any time you  
want - but in our experience, you very rarely need to since it covers  
so many of the common cases - date entry, selecting one (or more)  
related items, even an interface for reordering things via drag and  
drop.

Best of all, every time one part of the admin interface is improved  
(the date widget is made more usable for example) that improvement  
instantly propagatesto every application that uses the Django interface.

Cheers,

Simon Willison
http://simon.incutio.com/

On 16 Jul 2005, at 01:01, alex black wrote:
> Anyway: django _does_ have one thing over rails which I like, which  
> I''m sure others won''t: a proper template system.
>
> They appear to have copied smarty - which I think is great, I  
> always did like smarty. It''s possibly the most functional basic  
> tool implemented for PHP. binarycloud relies on smarty for all node  
> templates and it works freaking well.
Smarty was an influence (I''m pretty sure we pinched the idea of  
filters from Smarty) but we borrowed ideas from other template  
systems such as Cheetah, and came up with a few of our own as well.

I''m actually not at all opposed to the Rails template system -  
provided you are disciplined with it (and don''t drop in huge chunks  
of code) I think it works really well and the ability to add code  
makes it ultimately flexible. With Django''s templates it''s
possible
to need something which isn''t covered by the template language, in  
which case you have to write your own custom template tag in Python.

There are two principle reasons we went for our own template language  
over something like Rails'' embedded ruby system. Firstly, Python is  
poorly suited to embedding in HTML due to the way indentation in  
Python has a meaning (although since writing Django''s template system  
I''ve found a few clever embedded Python techniques that get around  
this). Secondly, we wanted to be able to have people modify templates  
without any chance of them breaking the whole system - either by  
accident or due to malicious intent. Since Python''s restricted  
execution module plain doesn''t work, writing our own system was the  
only way to do this.

Cheers,

Simon Willison
http://simon.incutio.com/

On 16 Jul 2005, at 08:14, 3kru-hpyd-5+VhGm8TZF7QT0dZR+AlfA@public.gmane.org
wrote:
> One thing nobody seems to have commented on is that Django seems to
> generate the database (rather than how Rails does it), based on
> defined classes in .py files. What happens when I decide I need to
> change something in one of my classes? Does it drop the entire
> table/database and start again (losing all data in the process)?
The SQL for table creation is generated and spat out on the command  
line rather than being run directly against the database, and it''s up  
to you to handle upgrading tables manually. We did try to build an  
automatic upgrading tool but it wasn''t reliable enough to be useful -  
reliably updating table structures is a surprisingly hard problem  
(although I''m sure it could be solved with enough elbow grease).

The reason we have data descriptions rather than introspecting the  
table (as in Rails) is that data descriptions let us add a bunch of  
extra information about the data being stored - things like  
validation rules and options for the auto generated admin. Rails  
achieves the same kind of thing using additional information in the  
model class. Personally I don''t see either technique as being  
particularly better than the other.

Cheers,

Simon Willison
http://simon.incutio.com/

+1


On 7/15/05 5:25 PM, "John Athayde"
<bobo-8WfjrGkLNeNByuSxxbvQtw@public.gmane.org> wrote:
> Why does everything have to be a "killer" It''s like
"iPod-killer"...
> 
> When will people stop basing business models on killing a good and powerful
> product with a large market share from a responsive and in most cases
> pro-active company?
> 
> Python people use Django. Ruby people use Rails. People who don''t
know either
> try em both out. 
> 
> On Jul 15, 2005, at 6:55 PM, Tomas Jogin wrote:
> 
>> 
>> Besides, it was labeled a
>>  
>> 
>> "Rails-killer" by Jason Higgins. 
>>  
> 
>  
> 
> --
>  
> 
> 
>  
> 
> John Athayde
>  
> 
> bobo-8WfjrGkLNeNByuSxxbvQtw@public.gmane.org 
>  
> 
> 
>  
> 
> Meticulous | www.meticulous.com <http://www.meticulous.com>  (work)
>  
> 
> Rotoscope | www.rotoscope.com <http://www.rotoscope.com>  (sound:
rock band)
>  
> 
> Boboroshi & Kynz | www.boboroshiandkynz.com
<http://www.boboroshiandkynz.com>
> (sound: electronic)
>  
> 
> Personal Weblog | www.boboroshi.com <http://www.boboroshi.com> 
(play)
>  
> 
> 
>  
> 
> "Those who would give up essential Liberty, to purchase a little 
>  
> 
> temporary Safety, deserve neither Liberty nor Safety."
>  
> 
>          - Benjamin Franklin (1706-1790)
> 
>                        Reply of the Pennsylvania Assembly to the Governor
> 
>                                  November 11, 1755
>   
> 
> 
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails



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

On Jul 15, 2005, at 3:52 AM, Colin Fleming wrote:
> I''d definitely be interested in seeing something like this. In
> particular I''d like an easy way to remove the requirement that
> dependent objects with a belongs_to relationship have a primary key as
> well as the foreign key.
I do have some relations (in the middle of a habtm) that use just two  
foreign keys as a combined primary key and do so just fine. They  
don''t have an id of their own (because that would break the data
model).

In my case, Markets habtm Manuscripts -- and vice versa. The join  
table is called Submissions.

from Submission''s model
class Submission < ActiveRecord::Base
         belongs_to :market, :order => "mkMarketName"
         belongs_to :manuscript, :order => "mssName"
         belongs_to :editor_reply
  [...]
end

I simply have to ensure that market_id and manuscript_id get set in  
anything where I need to find a specific record. For example the link  
to edit a record in list view is:

<%= link_to ''edit'', { :action =>
''edit'',  :market_id =>
submission.market_id,  :manuscript_id => submission.manuscript_id } %>

In submissions_controller.rb:
     def edit
         @pageTitle = "Edit Submission"
         @submission = Submission.find_by_market_id_and_manuscript_id 
(@params[:market_id], @params[:manuscript_id])
     end

find_by_market_id_and_manuscript_id is automagic with ActiveRecord.

Thanks bunches to the guys on #rubyonrails who helped me wrap my head  
around this.

On Jul 17, 2005, at 4:38 AM, Simon Willison wrote:
> There are two principle reasons we went for our own template  
> language over something like Rails'' embedded ruby system. Firstly,
> Python is poorly suited to embedding in HTML due to the way  
> indentation in Python has a meaning (although since writing  
> Django''s template system I''ve found a few clever embedded
Python
> techniques that get around this).
This quirk of Python''s, which doesn''t bother me *at all* when
using
it for command-line apps, is one of the reasons I never used Python  
much for web stuff. I found PHP much more accessible (and, at the  
time, I had some motivation as I was working at the same company as  
Rasmus).

Now I''m in the awkward position of having started a long-running  
Python group and not working with Python hardly at all.

-- 
_Deirdre                                             http://deirdre.net
"Cannot run out of time. There is infinite time. You are finite.  
Zathras is finite. This....is wrong tool."  -- Zathras

Another competitor:
     Cake  http://sputnik.pl/cake/

Bye !
François

Todd Grimason said the following on 2005-07-15 02:27:
> Looks like a worthy competitor is arriving on the scene (but not all the
> way through the door yet...)
> 
> http://www.djangoproject.com/

On Wed, 2005-07-20 at 10:42 -0400,
rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
wrote:
> Another competitor:
>      Cake  http://sputnik.pl/cake/
I started out trying to use Cake, since I''m coming from the PHP world,
but it''s still under *very* heavy development, and documentation is
still very sparse. But it seems very promising.

And yet another port of Rails I found this morning... this one''s
intriguing because it''s for JavaScript.
http://trimpath.com/project/wiki/TrimJunction

Alison

I love the code comparisons at that link you quoted - Ruby and
Javascript side by side. It really makes you appreciate the beauty of
the Ruby syntax :-)

Ben

On 7/21/05, Alison Rowland
<alison-6ZFeg8VWyaG5nc010YTXUQ@public.gmane.org> wrote:
...
> And yet another port of Rails I found this morning... this one''s
> intriguing because it''s for JavaScript.
> http://trimpath.com/project/wiki/TrimJunction