Hi,
Is there any tool for UI that RoR fraternity suggests? Any open source tool that we can use with Rails nicely? Or do i need to use dream weaver, golive for UI?
Regards, Sandeep G
IMO, if you care about maintainable, clean, portable HTML, you will write it yourself. Tools such as Dreamweaver and GoLive create such disgusting messes of HTML (usually fraught with tables) that anyone who picks up the project and doesn’t have said tool wants to seriously hurt someone.
That said, when doing Rails, if you’re doing anything dynamic you will end up with lots of small HTML partial files, which the likes of Dreamweaver and GoLive cannot properly handle.
Jason
I like Textmate on the mac, but the radrails plugin for eclipse in nice. I can use it on any platform.
I've used dreamweaver alot and I have thought about trying RoR in it but I am afraid it would junk it up. I will say dreamweaver is pretty good when you write your own code or for designing something fast (html, php, .NET or CF). I hope dreamweaver CS3 will have better CSS implementation.
Dreamweaver 8 isn't as bad as the other available options as far as HTML/CSS goes but to be honest there's no replacement for learning to write HTML and CSS by hand.
Jason Roelofs wrote:
IMO, if you care about maintainable, clean, portable HTML, you will write it yourself.
Google up my assert_xml, or write assert_tidy. Put it in the functional tests, and route all HTML thru it. (And write XHTML wherever possible.)
As you edit, frequently run the tests, and fix _anything_ that breaks or gives a warning.
That way, you don't grow a complex page and then discover, much later, you can't run assert_xpath on it.
Rails already throws warnings on functional tests for HTML that isn’t proper XML. Granted they aren’t amazingly good error messages, but as long as you’re constantly running tests, you will know the last thing you changed.
As for assert_xpath, Rails integration tests (and functional, but it’s meant for integration) now has assert_select (replacing assert_tag) that allows you to use CSS selector strings for testing rendered content. This can work just like XPath as well, if you’re testing pure XML. e.g.
assert_select “root-node child-node”, :count => 10
assert_select “child-node” do assert_select “name”, :text => “Node name” … end
Jason
Jason Roelofs wrote:
Rails already throws warnings on functional tests for HTML that isn't proper XML. Granted they aren't amazingly good error messages, but as long as you're constantly running tests, you will know the last thing you changed.
? I never noticed Rails gave a darn about ill-formed HTML. What test service are you talking about?
As for assert_xpath, Rails integration tests (and functional, but it's meant for integration) now has assert_select (replacing assert_tag) that allows you to use CSS selector strings for testing rendered content. This can work just like XPath as well, if you're testing pure XML. e.g.
My main beef with assert_select is I can never figure out how to write any of the queries that its advertisements come with. This beef synchronizes with the beef that its diagnostics don't actually say what's going on. I think they just say "nil should not equal nil".
And assert_select accepts HTML that has broken tags and such.
I want the highest possible XHTML-ready content. One reason is so I can add an assert_xpath to anything, retroactively, to fix a bug, without stopping to clean up the damned tags. (You might notice I'm coming down from some recent experience here!)
Next, I'm going to write assert_tidy, and it will pipe @response.body thru tidy. That will print out every Error, and then every Warning not appearing in a white-list. I need all my minions to add assert_xml _and_ assert_tidy AND assert_select to multiple tests on every feature of every page.
That way, when the time comes to change a page, I can add any of these assertions and immediately isolate the target problem, without spending time upgrading the friggin' tags.
Browser forgiveness is for people who still write websites in static HTML with Notepad.
Jason Roelofs wrote:
Rails already throws warnings on functional tests for HTML that isn’t proper XML. Granted they aren’t amazingly good error messages, but as long as you’re constantly running tests, you will know the last thing you changed.
? I never noticed Rails gave a darn about ill-formed HTML. What test service are you talking about?
Ill-formed XML. e.g. it will complain if you miss an end-tag or misspell something (
… ). It’s not an HTML validator, if that’s what you’re talking about.
As for assert_xpath, Rails integration tests (and functional, but it’s meant
for integration) now has assert_select (replacing assert_tag) that allows you to use CSS selector strings for testing rendered content. This can work just like XPath as well, if you’re testing pure XML. e.g.
My main beef with assert_select is I can never figure out how to write any of the queries that its advertisements come with. This beef synchronizes with the beef that its diagnostics don’t actually say
what’s going on. I think they just say “nil should not equal nil”.
And assert_select accepts HTML that has broken tags and such.
I want the highest possible XHTML-ready content. One reason is so I
can add an assert_xpath to anything, retroactively, to fix a bug, without stopping to clean up the damned tags. (You might notice I’m coming down from some recent experience here!)
Next, I’m going to write assert_tidy, and it will pipe @ response.body thru tidy. That will print out every Error, and then every Warning not appearing in a white-list. I need all my minions to add assert_xml and assert_tidy AND assert_select to multiple tests on every feature
of every page.
That way, when the time comes to change a page, I can add any of these assertions and immediately isolate the target problem, without spending time upgrading the friggin’ tags.
Browser forgiveness is for people who still write websites in static
HTML with Notepad.
– Phlip http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!
Understood, and I’ll be sure to check it out. Just try to keep it from slowing down tests anymore than they already get with large Rails sites :D.
Jason
Jason Roelofs wrote:
Ill-formed XML. e.g. it will complain if you miss an end-tag or misspell something (<div> ... </dvi>). It's not an HTML validator, if that's what you're talking about.
Thanks, but by "test service", I mean the thing that everyone else in the industry calls a "test fixture". The function in the test-side code that does this detection. (And I don't mean a Rails test "fixture"!)
I have never seen such an error. I can call 'get :index' in a page, put crap in 'index.rhtml', and the 'get' won't complain. So what test service are you talking about?
(You are not Edgy, are you?)
Jason Roelofs wrote:
Ill-formed XML. e.g. it will complain if you miss an end-tag or misspell something (
… ). It’s not an HTML validator, if that’s what you’re talking about.Thanks, but by “test service”, I mean the thing that everyone else in the industry calls a “test fixture”. The function in the test-side code that does this detection. (And I don’t mean a Rails test
“fixture”!)
I have never seen such an error. I can call ‘get :index’ in a page, put crap in ‘index.rhtml’, and the ‘get’ won’t complain. So what test service are you talking about?
(You are not Edgy, are you?)
– Phlip http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!
response.body, whether it’s custom or from Rails such as assert_tag or assert_select will though. It’s done this since I started with Rails in the 0.4 days.
Jason
Amen to what he said, flippin notepad or gedit!
But if you want to play around in an IDE, RadRails for eclipse is nice and So Is Netbeans RoR module, both have their quirks but the Netbeans option has integrated API searching/autocomplete/ help.... I wish I would have had that like 8 months ago when I was using gedit in one window and browsing the API with another....
Hope that helps
