SitePoint Sponsor |
|
User Tag List
Results 1 to 17 of 17
Thread: Ruby and Standards
-
Jan 11, 2006, 14:33 #1
- Join Date
- Nov 2003
- Location
- New Jersey
- Posts
- 195
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Ruby and Standards
Hi everyone,
I am wondering how well does ruby comply with web standards. I watched part of that video where the guy creates a weblog in 15 minutes. That is great, but if the html that is created is total crap, then I know for me, its totally worthless. So, can I develop with Ruby apps using standards based design. Just to clarify, when I say standards I mean strict XHTML, tableless design using CSS and all of that stuff.
Joe-- Joe C --
"Do or do not. There is no try..."
- Yoda
-
Jan 11, 2006, 14:48 #2
That's all easily doable with Rails, since the functions that return HTML tend to comply with XHTML.
You do have to watch out for ugly Javascript though. Using Rails's built-in functions like link_to_remote can leave you with a link like this:
HTML Code:<a href="#" onclick="new Ajax.Request('/test/123');">Test</a>
-
Jan 11, 2006, 15:18 #3
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
In this day and age, you really shouldn't attach an event handler to an element in that manner; Instead what you do is to attach the event handler to the element from within javascript, via the DOM is needs be,
Code:<head> ... // my javascript is a bit rusty, but... a = document.getElementsByTagName( 'a' )[0]; // then attach event handler this way
Code:<a href="#" onclick="new Ajax.Request('/test/123');">Test</a>
-
Jan 11, 2006, 15:55 #4
Originally Posted by Dr Livingston
-
Jan 11, 2006, 16:17 #5
- Join Date
- Nov 2004
- Location
- Romania
- Posts
- 848
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Dr Livingston
Manipulating the DOM tree for such simple things as event designation is worthless and error-prone.
And when you see a link like:
<a href="javascript:void(0);" id="myLink">Test</a>
What does the link tell you about its destination ?
Wouldn't you have to look in another file. where the javascript is, and search for the piece of code that assigns to element `myLink`the onclick event ?
And yes, in this day and age the javascript has to be in another file because that's the way search engines like it.
-
Jan 11, 2006, 17:26 #6
- Join Date
- Jan 2001
- Location
- Lisboa : Portugal
- Posts
- 418
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
They recently added RJS templates, which I haven't tried out yet, but seem to address this problem.
An intro to RJS templates: http://www.codyfauser.com/articles/2...-rjs-templatesDuarte Carrilho da Graça
RailsHelp.com: Searchable Rails reference
CACA: Committee for the Annihilation of Complicated Acronyms
-
Jan 11, 2006, 18:53 #7
RJS templates don't completely solve the problem but you can forgo the built in AJAX helpers like link_to_remote and integrate using your own scripts and something like the behavior library.
-
Jan 12, 2006, 11:29 #8
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Bonefry,
My comments were in reference to web standards, from what I can recall the W3C suggest that putting event handling within HTML is wrong; That is why I suggested the alternative. Consider the oft debated topic of putting PHP within HTML - it's the same principle really, and for the same reasons actually
Weather or not the Javascript resides in a separate file is not here nor there, if like me you build up the page dynamically, you can put functional Javascript for that specific page, and no other, within the HEAD of that template fragment, ie
PHP Code:<head>
<?php echo( @$nodes['header'] ); ?></head><body>...
Does anyone know of any search engines that actually search a Javascript file? I don't... The major engines usually ignore the <script /> tag. The reason you use a separate file is for the same reasons CSS is a separate file; definitely not because of search engines
That isn't really the point anyway, the point is complying with web standards, and following them standards.
They suggest don't embed your Javascript, you of course, can suggest something else
-
Jan 12, 2006, 12:06 #9
- Join Date
- Aug 2005
- Posts
- 986
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I suggest that you do the simplest thing. You don't embed javascript in your HTML because it will be hard to maintain. If you are using link_to_remote it makes it easier to maintain than having javascript in your head-tag.
I think that you should not just follow web standards because they are webstandards, and therefor right. You should do what fits best, and link_to_remote fits perfectly most times.
But what is the bad XHTML in the video? The HTML that gets generated by link_to/etc is XHTML strict. Tables are used for tabular data, correct. And you can alter all HTML that is outputted, even the HTML of built-in functions like link_to().
-
Jan 12, 2006, 12:46 #10
- Join Date
- Jan 2001
- Location
- Lisboa : Portugal
- Posts
- 418
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
You can always decide not to take advantage of rails' built-in javascript helpers, and do it your way. You can even still take advantage of rails routing while doing it, for instance, instead of link_to_remote, you can use
Code:<a href="<%= url_for :controller => "bla", :action => "bla" %>" id="bla">
Duarte Carrilho da Graça
RailsHelp.com: Searchable Rails reference
CACA: Committee for the Annihilation of Complicated Acronyms
-
Jan 12, 2006, 13:41 #11
- Join Date
- Aug 2005
- Posts
- 986
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
But that would produce the same HTML as link_to ;-)
-
Jan 12, 2006, 14:22 #12
- Join Date
- Jan 2001
- Location
- Lisboa : Portugal
- Posts
- 418
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Fenrir2
Code:<%= link to "bla", {:action => "bla", :controller => "bla"}, {:id => "bla"} %>
Duarte Carrilho da Graça
RailsHelp.com: Searchable Rails reference
CACA: Committee for the Annihilation of Complicated Acronyms
-
Jan 18, 2006, 15:50 #13
- Join Date
- Mar 2005
- Posts
- 251
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I'm with the Dr on this.
having onclicks in your html is the equivalent of wrapping font tags around your html.
the three layers of separation are content, presentation and behaviour. The only way to produce valid html documents at the moment is to use the behaviour library and link behaviours to CSS selectors.
A list apart did an article about a year ago which suggested creating a custom attribute.... ie.
<a href='link' behaviour='behaviour'></a> but to get that to validate you have to create your own DTD. So in my opinion, behaviour library is the best way to go at the moment.
-
Jan 18, 2006, 18:12 #14
Also, there isn't really a valid reason for creating a custom attribute as there isn't anything that says class cannot be used to indicate behaviour. Its simply used to classify elements whether that be by behaviour or style.
-
Jan 19, 2006, 06:06 #15
- Join Date
- Aug 2005
- Posts
- 986
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
This is interesting:
http://bennolan.com/behaviour/
Use classes and hook up Javascript with CSS selectors.
-
Jan 21, 2006, 20:22 #16
- Join Date
- Jun 2004
- Location
- Stillwater, MN
- Posts
- 96
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
There was a big discussion about Rails's inline JS helpers on the mailing list:
http://thread.gmane.org/gmane.comp.l...by.rails/15668
The conclusion was that the core team didn't think that it was worth the necessary effort.Rad Smith
My blog
-
Jan 22, 2006, 18:51 #17
- Join Date
- Jul 2004
- Location
- Gerodieville Central, UK
- Posts
- 446
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Going back to the point, The markup you produce is totally independant of Rails it's self and you have total control when you edit the templates. You will find most rails applications do spit out good quality CSS / XHTML as most Rails users are web-standards aware.
While Rails has scaffolding which again produces reasonable quality XHTML, you will want to move code away from scaffolding, as many suggest for reasons totally unrelated to markup.
The onclick stuff that's mentioned abover can safely be ignored. 99% of the time you will not want to be using AJAX, and any well designed application should be able to be functional without the use of AJAX (unless it's something very unusual). You will probably only need to use AJAX for more demanding interfaces, which generally speaking tend to be restricted to admin backends etc, where it's not so bad to expect users to have JS to be enabled (likewise I'm not quite as fussed in admin backends about markup, as I'll use the odd table here if it makes life a lot easier)
Bookmarks