Rhostudio intellisense, code-behind, graphical development

[Egghead]

I come from a MS VS.NET background, wonder if it would be possible for Rhomobile to build in the future a Rhostudio with intellisense, code-behind, graphical development. Right now those .erb files remind me of classic ASP where markup and server code are interspersed, not sure if a ruby-based framework that supports code-behind features like Visual Studio can be developed or already exists...what are your thoughts on this, folks?

[Adam Blum]

Intellisense is in the roadmap.  Drag and drop layout for creating HTML5 based templates is not something that we would likely do.  However there are other tools in that space that could be used to create Rhodes views. 

On Tue, May 1, 2012 at 9:08 AM, Egghead <mark.no...@gmail.com> wrote:

I come from a MS VS.NET background, wonder if it would be possible for Rhomobile to build in the future a Rhostudio with intellisense, code-behind, graphical development. Right now those .erb files remind me of classic ASP where markup and server code are interspersed, not sure if a ruby-based framework that supports code-behind features like Visual Studio can be developed or already exists...what are your thoughts on this, folks?

--
You received this message because you are subscribed to the Google Groups "rhomobile" group.
To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/vgUQOaLNa5AJ.
To post to this group, send email to rhom...@googlegroups.com.
To unsubscribe from this group, send email to rhomobile+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhomobile?hl=en.

[Jon Tara]

On Tuesday, May 1, 2012 9:08:50 AM UTC-7, Egghead wrote:

code-behind, graphical development. Right now those .erb files remind me of classic ASP where markup and server code are interspersed

Only if you mis-use it. You shouldn't be putting much code in your .erb files. If you're tempted to put code in your .erb and it pertains to presentation, it belongs in the controller. If it pertains to data, it belongs in the model. Most of the abuse you see (both in Rhodes and in Rails) is writing database .find() code directly in the .erb. That's a big no-no - don't do that!

I dislike graphical development tools that make you drag this and that all day, rather than just writing code in a file. It's what I most dislike most about XCode.

[Adam Blum]

I dislike graphical development tools that make you drag this and that all day, rather than just writing code in a file

+1 

--

You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/jgiWq3by98QJ.

[Egghead]

Thank you, Adam. At least we're getting intellisense.

" However there are other tools in that space that could be used to create Rhodes views. "

Could you mention some, please?

@Jon, yes I agree that we have to understand & be careful what we put into M,V & C, but sometimes we need to be able to view how the markup would look like in the editor itself, minus the <= (fields pulled from a database). How do you normally do that?

[Jon Tara]

On Tuesday, May 1, 2012 6:30:06 PM UTC-7, Egghead wrote:

but sometimes we need to be able to view how the markup would look like in the editor itself, minus the <= (fields pulled from a database). How do you normally do that?

Use standard HTML/Javascript debug tools (Firebug, Web Inspector). Or just "view source" in a browser. (BetterSource is a nice plugin alternative, though.)

You can set the server to connect to a consistent port for debugging. In rhoconfig.txt, uncomment the line for set_server_port. Then you can connect to localhost:8080/app in your browser, if running the simulator. If running on a device, substitute your device address.

It's not quite the same as "the page without the <% %> , because you will also see the class names that jQuery Mobile has added to elements.

[Adam Blum]

Any "graphical HTML generator" should do the trick. I know Dreamweaver did this at one time. Since I am skeptical of "graphical HTML layout" in general (like Jon) I wouldn't be the person who would know.    Perhaps someone from the community can chime in here.  

--
You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/Qq_rSq9jfcsJ.

[Egghead]

The code-behind in Visual Studio was to address the requirement of separation of concerns - GUI designers separate from coders, plus it doesn't force anyone to use drag and drop, anyone who prefers to punch out the markup plus code was welcome to do so, in source view, the tool didn't prevent that, the options are open, I'm thinking it could be useful in a collaborative environment like Rhohub where this separation of concerns could come in useful amongst the collaborators who might be a mix of designers and programmers. Your thoughts?

[Jon Tara]

You would need to work in an environment where jQuery Mobile (or alternative - jq.mobi, Sencha Touch, etc.)  is loaded, and used during rendering of the previews or WYSIWIG views. You might want to see what tools are available for developing regular websites using JQM, etc.

The fact that you could swap Javascript frameworks is a problem that Microsoft doesn't have to deal with.

I see your viewpoint. But I don't think you'll find what you're looking for. It would have to be a more stable and cohesive environment (which Microsoft has).

Best to work on strategies that allow you to better separate concerns. So, prototype pages using a browser, provide some dummy data (what does Visual Studio do about that? Sorry - I haven't used Visual Studio in years...), then take the result and turn it into .erbs. You replace the dummy data blocks with <%= > tags.

You could perhaps automate some of this. If you keep logic out of the .erbs, it could be as simple as coming up with your own proprietary tags, and using a general-purpose macro processor. You could come up with a few proprietary tags. You (or your designer) writes HTML with these special tags into, say, a .erbpre suffix. The macro processor can generate either an .erb, a .html, or both.  When generating an .erb, it would replace the proprietary tags with <%= %> tags. When generating an .html, it would replace them with dummy data either from files or from a test data generator.

You might want to see how Rails developers deal with this issue, since Rhodes has much in common with Rails.

I worked on backend admin stuff in Rails at a major console gaming studio. For admin stuff, programmers designed the pages and generally worked directly with the .erb file - they don't need to be so pretty. For the public websites (leaderboards, etc.), a designer did it using Adobe tools, using dummy data, then handed the HTML to a programmer, who turned the .html into .erb. No, the process doesn't provide instant feedback, but feedback in that situation was a couple of cubicles away.

Here's a page that I think describes the situation and offers a solution - albeit for an obscure framework written in Scala:

http://demo.liftweb.net/templating/

[dmi...@rhomobile.com]

RubyMine is also very good for ruby/rails/rhodes and just great for html/erb/css/js/jqm

I wish eclipse will have such a powerful features for html/css/js.

Sent from my BlackBerry® wireless device

---

From: Jon Tara <jtara-g...@spamex.com>

Sender: rhom...@googlegroups.com

Date: Wed, 2 May 2012 11:09:43 -0700 (PDT)

To: <rhom...@googlegroups.com>

ReplyTo: rhom...@googlegroups.com

Subject: Re: [rhomobile] Re: Rhostudio intellisense, code-behind, graphical development

--
You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/FkYlWiUvptkJ.

[Egghead]

Will try to explore those mentioned tools and suggestions, but they are all external tools, I was looking forward to the possibility of turning Rhostudio into a full-fledged IDE and RAD tool, and I mentioned VS.NET as I'm familiar with it, there may be better appropriate comparisons.

May I mention that in VS.NET, there's also the concept of a masterpage, where content and links that need to appear across pages of a site can be defined and programmed against. This concept seems to be quite appropriate for Rhodes apps too since we need things like the toolbar to appear on every view, but the html is being repeatedly typed in several erb files, a rather boring exercise. Or maybe I'm missing something here. VS.Net also allows use of jQuery and other scripting frameworks, though I've not explored these options yet. But again, I'm just doing an analogy here, I'm not biased against Rhostudio or other tools, just putting out my thoughts with an open mind here.

[Jon Tara]

On Thursday, May 3, 2012 6:40:21 PM UTC-7, Egghead wrote:

Will try to explore those mentioned tools and suggestions, but they are all external tools, I was looking forward to the possibility of turning Rhostudio into a full-fledged IDE and RAD tool, and I mentioned VS.NET as I'm familiar with it, there may be better appropriate comparisons.

I don't think that the size of the Rhodes market is large enough to justify th effort needed for this. Do you have any idea the number of man-years behind Visual Studio?

 

May I mention that in VS.NET, there's also the concept of a masterpage, where content and links that need to appear  across pages of a site can be defined and programmed against. This concept seems to be quite appropriate for Rhodes apps too since we need things like the toolbar to appear on every view, but the html is being repeatedly typed in several erb files, a rather boring exercise. Or maybe I'm missing something here.

You are. layout.erb

[Jon Tara]

On Friday, May 4, 2012 10:04:34 AM UTC-7, Jon Tara wrote:

Or maybe I'm missing something here

You are. layout.erb

You can also use partials, in case you have something you don't need to have on EVERY page. If you have, say, a header that you use on a few pages, define it as a partial, and call the partial from those pages.

Really, it's better to break pages up into several partial anyway. Makes maintenance a lot easier. It's low overhead. .erb files are converted to Ruby, and the Ruby is compiled to byte code, and the byte code is loaded into the interpreter at runtime. Calling a partial is basically a function call overhead.

[Mark Nongkhlaw]

Most valuable comments, thanks, will keep these tips in mind as I go along with Ruby/Rhodes...can you please give code example of partials?

--

You received this message because you are subscribed to the Google Groups "rhomobile" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhomobile/-/ZyhvTAeTbj8J.

[Jon Tara]

You might want to consider using a static site generator. e.g. jekyl, hyde, webby.

These are designed for producing static websites while doing some macro substitution. You typically get your choice of macro language(s) and can even apply multiple macro languages to the same file.

webby looks pretty good to me.

With webby, you can take one of your ERB page designs, and give it the page and some test data, and it can spit-out a finished page that can be viewed in a browser, without having to run your app.

You can also use it to break-out common headers, footer, etc. and then have it produce the ERB files for your app.

[Egghead]

Read somewhere in the docs that Visual Studio can be used, is there a way by which it can be made to run Ruby code? In fact, it looks like it's a requirement for building for win mobile. If that's the case, then for devs coming from VS we can use it in lieu of Rhostudio.

[Egghead]

Looks like I'll need IronRuby with VS. Not sure about the pros and cons, though, e.g., I don't think I'll get Rhosimulator. Anyone here has done Rhodes development using VS?

[Egghead]

[Arquimidez Mora]

Hi,

The last time i saw, on the main page of jquerymobile.com there was a UI builder powered by codiqa, you drag and drop and then
is just download the html file and paste the content of the <body> part on your .erb