in my project i have about 20 html forms with many different <input>'s. This <input>'s are unique in every form and they don't repeated between them. For each form there is a script which get data from form, generate specific file, and push it to the browser. and that's it. no databases, admin, logins/passwords and other usual web-app stuff.
so for example in php, project structure can be something like this:
forms/
------->form1/
--------------->index.html
--------------->script/
----------------------->index.php
------->form2/
--------------->index.html
--------------->script/
----------------------->index.php
and so on. It's quite clear and it makes pretty urls like:
www.website.com/forms/form1
but in Ruby-on-Rails there is a MVC pattern. And i have no idea how to organize structure with project like that. How to make it right? I should not to make 20 different controllers after all, right?
Yes you do make 20 controllers. In much the same way as you have 20 script/index.php files in your PHP structure. The rails structure would look something like this.
app/
controllers/
form1s_controller
form2s_controller
.....
formns_controller
view/
form1/
new.html.erb
form2/
new.html.erb
......
formn/
new.html.erb
layouts/
application.html.erb
Where the controllers have a method for each action that you want to perform e.g. new, edit etc
The layouts/application.html.erb file will contain all of the markup that is consistent across all of your pages.
Finally, don't try and fight the structure. It is there to enable minimal code because of convention, if you try and create your own structures you will create a world of pain.
Since there is no database backend for the forms, i would create one FormsController, with 20 methods (form1, form2, form3, ...).
Your urls would then look almost the same \forms\form1, \forms\form2 ...
Even if you would use 20 controllers, there are many ways in ruby to remove duplicate code. So even in a normal MVC, i have had applications with 140 models, and likewise as many controllers, most of these controllers had only one line and the views were completely generic.
Just because a certain solution seemed simple in PHP, it doesn't mean better solutions don't exist. Like for instance MVC. It might seem to induce more code, more files, more work, but the structure is there for good reason, it seperates the concerns cleanly, and each file in itself becomes more clear and easier to understand.
Related
I've got two grails projects (admin backend and frontend) using the same domain classes from a local plugin.
I need to have different views in the frontend and the backend. E.g. there's a domain class Event. In each of the projects I use GenerateViews. Then I modify the generated gsps. As an example take the list.gsp. In frontend I remove the actions to create a new event from the view and the Controller, in the backend I keep them. That's because in the frontend the users should be only able to see the list of events, while in the backend the admin creates and modifies what is displayed in the frontend. This is the structure I get:
project domain
domain/grails-app/domain/myapp/Event.groovy
project frontend (grails.plugin.location.'domain' = "../domain")
frontend/grails-app/controllers/myapp/frontend/EventController.groovy
frontend/grails-app/views/event/list.gsp (no links to edit / create action)
project backend (grails.plugin.location.'domain' = "../domain")
backend/grails-app/controllers/myapp/backend/EventController.groovy
backend/grails-app/views/event/list.gsp (links to edit/create...)
But when I run my frontend application using run-app, and go to list, the controller is called:
def listEvents(Integer max) {
params.max = Math.min(max ?: 10, 100)
[eventInstanceList: Event.list(params), eventInstanceTotal: Event.count()]
}
and as a result backend/grails-app/views/event/list.gsp is rendered instead of frontend/grails-app/views/event/list.gsp.
The confusion already begins when I'm generating the views. So when I generate views for domain/grails-app/domain/myapp/Event.groovy inside the backend project everything is fine. The views get created inside my backend projectand work as intended.
Then I move ober to the frontend project and generate views for domain/grails-app/domain/myapp/Event.groovy. This time grails will tell me that there already are views, and asks if I want to replace them. If I say yes, it doesn't replace anything, but create the views in my frontend project. Really weird.
I found that there is an older bug report related to this, and I created a new one (http://jira.grails.org/browse/GRAILS-9920).
In the meantime, what should I do to work around this? I could rename my controllers' methods and the views, but I hope that there's a better way. It seems odd, that a view by the same name may override a view in a separate project. Or does something like that only happen when using run-app?
I'm new to Grails, so maybe I missed something obvious, but this really scares me, since it looks like I might accidentally expose actions in one project by modifying the other.
I've been searching and trying to learn for ages but it just doesn't stick. There seems to be only 1 tutorial on Zend 2, and it's not very smart. Here we have a sample structure (and the tutorial proceeds with this application) http://framework.zend.com/manual/2.0/en/user-guide/modules.html :
zf2-tutorial/
/module
/Album
/config
/src
/Album
/Controller
/Form
/Model
/view
/album
/album
That's not cool - how do I know which album is which? In Zend 1 it made a lot of sense - you have modules, then you have controllers, and those controllers have actions.
Now I have a module called Album. is the src/Album/... a "single controller"? Would:
zend1application/modules/album/albumcontroller.php map to zend2application/modules/album/src/album/controller/albumcontroller.php? In that case, why are there 3 albums now? Like what happens if I change albumcontroller.php to indexcontroller.php? (I have been testing but there are so many changes it never sticks - I finally thought I should ask someone and if I know why I'll remember.
If I look at it a different way it seems the Album in module/Album and module/Album/src/Album should be the same - then why would we have it twice? Doesn't that just make room for error? Like why have a src/album folder? Why not put Controller, Form, and Model under module/Album?
Why is there a folder called Controller? There used to be a folder called controllers (plural, why singular now?) in a module before, that makes sense. But why is/are controller(s) inside a src/Album folder now?
Thank you for your time. I have tried to research but I think it's just too big absorb when (in my opinion) it seems so sparsely documented. Or, if someone could point me to a book like http://survivethedeepend.com/ but for ZF2, it'd be greatly apprecated.
Zend Framework 2 follows PHPfigs PSR-0 Standards. This means that the directory structure directly relates to the classname. But before i come close to that, let me explain the basic architecture.
First you have the ModuleNAME. Since the Module name needs to be unique, it only makes sense to map the Modulename to the Namespace of your model.
Inside the modules folder you have three sub-folders. One folder for configuration items named config. One folder for source-code files named src and one additional folder for the view files view
This separation is simply for overview. You separate configuration, view and sourcecode from another. It makes no sense to bunch them together and i guess you'd agree. This pretty much has been the same for ZF1, too.
The interesting part is the source-folder src. Earlier i mentioned about the PSR-0 Standard. And this is the place where it comes into effect. By default the source-files for each module will be looked upon from the source-folder src. So whenever you have a class, it will be using PSR-0 Standards based off of the source-folder. Mewning: My\Funky\Class would be found within src\My\Funky\Class.php
And that's basically all there is to it. Controllers usually have a FQCN like Mymodule\Controller\SomeController so you will find this class inside src\Mymodule\Controller\SomeController.php
The main question arising could be: Why are the folders sometimes all lowercase and sometimes ucfirst. The answer, once again, is PSR-Standards. Classnames and/or Namespaces are supposed to begin with an upperchar character. And since path-names are case-sensitive, the folders need to match the classnames exactly!
EDIT Another nice read i've just stumbled upon is Rob Allens latest blogpost: Thoughts on module directory structure. He explains how you can change the default setup quite easily to your likings.
I have one companion script file for a Rails model, that uses code I've broken down into a hierarchy of over a dozen classes, for things like jQuery/Bootstrap UI code, factoring out similarities between different types of dialog, and so on. Let's say I'm working with articles.js.coffee as the "main page script" here.
I can define Coffeescript classes, namespace them as something like window.ourproject.OurUIDialog, and save them in separate, per-class source files such as app/assets/javascripts/OurUIDialog.js.coffee. Restart the Rails server, and that class can be subclassed, e.g., window.ourproject.PostInfoDialog extends window.ourproject.OurUIDialog. As long as PostInfoDialog is in articles.js.coffee (where the instantiation of the PostInfoDialog is), all is well.
But, if I move the subclass (PostInfoDialog) out into a separate file, e.g., PostInfoDialog.js.coffee, then attempting to do anything at all with it within the main articles script produces
Uncaught TypeError: Cannot read property 'prototype' of undefined
Again:
This revolves around a Rails model's companion script file, here called articles.js.coffee;
window.ourproject.OurUIDialog gets picked up whether it's in its own file or in articles.js.coffee
window.ourproject.PostInfoDialog (which extends OurUIDialog) can only be used if it's not in a separate file, even though viewing the generated HTML shows PostInfoDialog being included with all the other script files.
I'm tearing my hair out trying to figure this out, and I didn't have much left to begin with. Any ideas?
Pretty sure that Trevor Burnham answered my question when he answered this one; I just didn't see it the first dozen times I searched. :-P
Thanks to both of you for reading this one, though. :-)
I wanted to get a general idea from other RoR coders out there as to the benefits of using partials if the code that the partials are pointing to are only a few lines (5-10 lines). By using Partials wouldn't it make it more complex in terms of going to files to view what is in the partials instead of seeing what is in the file itself?
This thought came up while trying to decide whether to use partials or not in my application.html.erb under my views/layout directory. I want to produce elegant code and the structure. Thanks for all your help.
Partials are very similar to functions/methods. When your function starts getting long, you break it into multiple functions to make things clearer. When some bit of code appears in more than one function, you refactor that bit into a separate function.
Sometimes you pass a container into a function and make it iterate over it, other times it's better to write a function that handles just one element. It's the same with partials.
I try to use partials whenever I feel it will clean up my code. Especially if you are re-using the code in any other section of your site. I often will put loops into partials too.
User.all.each do |user|
render :partial => do_stuff, :locals => {:user => user}
end
This way, if I ever need to change this, it's easy to find, and the code is separated from my other layouts/views. It's good to separate different features or aspects of your views into their own files. Although you will have more files, it should greatly assist you in the long run.
If someone asks you for a hotfix, you may have a better idea of where to go to make your change.
A great IDE also helps for navigation through your methods and whatnot. Rubymine is excellent for this.
I hope this helped some.
Recently I created a spike of a view engine, in which views are plain classes, and the content is created by using funny using-scope blocks.
The code together with a simple sample site is available at http://code.google.com/p/sharp-view-engine/
Here I'd like to hear your opinions regarding such an idea. Is it completely weird or maybe someone likes it?
I would actually not like that.
I can agree with DSLs (such as a Parser-Combinator or for generating XML Nodes in a data-context), but in this case I think that too much is being put in code that. And, in the end, this just complicates boundaries and leads to hard-to-maintain code. (You can already do the same, but with more verbosity just using the "standard" Web Controls. You can always use {subblock} in C# to limit a variables scope.)
The approach I prefer to use is templates with bindings (but no "code in templates"). That makes it easy for the "designer" (hopefully not me, or the next person to come along and) edit the layout of the view how they see fit. However, the core logic (the available controls and bindings) are kept in the code -- uncluttered. (Another advantage with the templates is that if they externally housed they do not require a recompile for every little change.)
Simplicity and maintainability are like ... zen.
This is an interesting idea taken to the extreme I'd say. At my shop we're using html conventions for pretty much everything except our layout. The only real html we have in the project is our Spark master page. For generating the content itself we use a convention engine that that spits out a semantic html model. (We're using the HtmlTags library from FubuMVC to build the semantic model.)
An example convention for rendering a multiline text box looks like:
public static HtmlTag Build(ElementRequest req)
{
return Tags.TextArea
.Rows(6)
.Id(req.ElementId)
.Attr("name", req.ElementId)
.Text(req.StringValue());
}
These conventions get triggered from reflecting on the view model (or we can manually call them from a helper method). The output is rendered (via ToString()) into the content section of our master page. We're joking that pretty soon we won't even need a view engine.
ps here's how we handle nesting. (Your using blocks look cluttered!)
return Tags.Div.Nest(
Tags.Button("save").AddClass("positive"),
Tags.Span.Text(" or "),
Tags.Anchor.Text("cancel").AddClass("negative")
);
Nest() is an extension method that simply takes a params array of HtmlTag and appends them to the parent's children collection.