UI tool with RoR?

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