Symfony admin generator: To be or not to be? - symfony1

on the last projects i've started, I wondered if I should use the admin generator or not. My usual choice is to not use it, as some developers suggested to me, "unless it's for quick backend prototyping and submission to client", they said. Currently i'm starting a project and i'm in the situation that the client need the backend very fast to start loading lots of data, and i'm doubting about using the admin generator or not. I would use it if needed simple form fields. But one of my models must have multiple images, and maybe I need a more complex view that allow the client to load N images, so the admin generator maybe it's not the best choice, but it seems fast, it seems to save time and that's what I need now, time saving!
The project is very simple, it's just a Product model with multiple images and multiple sizes and belongs to a simple category.
What do you think? What would be the best option for this? And where do you think that makes sense to use the admin generator or the regular module generator?
Thanks in advance!
Regards.

I use the admin generator as much as possible. It is really designed to be great for the "backend" of your website-- the administrative screens which authors and editors will use to maintain the app. Any module that needs to be user-editable and is simple cries out for the admin generator.
Recently I have been starting everything with the admin generator so that there's a working prototype to build data with. Then I select certain modules or views that need more magic sauce, and build them out with more customization.
Remember, you can add views and forms to an admin generator module. On my last project I used the admin generator for the "edit" action of my main object but added "show" methods similar to a non-admin-generator form-- adding an executeShow() action and showSuccess template.
The other thing to keep in mind is that the admin generator is only a generator. It writes a bunch of code for you in cache/frontend/env/modules, but you can override any of it by building the equivalent code in apps/frontend/modules/. If you find one part of it that you can't configure with generator.yml, you can copy the file out of the cache into your module dir and hack away. I prefer to take the "out of the box" admin generator as far as possible before customizing it, though.

i've been working with symfony for quite some time now and i've been using the admin generator for simply and complex situations. It's true that it saves time when developing CRUD modules, but i dont think that is not advisable for complex cases.
I think you should use it and also learn the power of customization the generator gives you. If you have complex Forms, leave that for form classes to manage and as you said, if your forms a quite more complex to render, well you should only take care of the rendering of that only segment of the view.
But, if you decide to make if without it, you should start thinking about creating all the view from scrap, that in my case takes quite time ( i'm not so versatile wiht css).
But this is only my opinion, hope this helps you make a more rational choice!

Related

What are the steps for modifying an existing rails application

I am new to ruby on rails and I am working on a web application written by ruby on rails. It has more than 10 models and I need to add some new attributes to some of the models as well as new methods and views. I also will need to remove or enhance some of the functionality. I know that I would need to generate new migrations and from there add/remove new columns. Then in controllers, add/modify methods, and update the views.
I wanted to know what would be the best steps (and in which order) for doing the above tasks. Also, do I need to change other files in folders like test or any other folder? What things should I consider to minimize the troubles later?
Thanks in Advance.
Since you are new to rails, the first thing you should do is to read through the getting started guide. This will help you understand the fundamentals of the rails framework and the application you inherited. After that, there are several other guides worth reading (from the same site) that may be directly applicable to the work you are doing.
Another incredibly helpful resource is railscasts. Some of these are outdated, but they are still a great starting place and can help introduce you to both new, powerful gems and rails techniques to get the work done faster and better.
As to your specific question, rails is built on an MVC architecture (meaning Model Views Controllers). It is in your best interest to try and follow this practice whenever possible. Reading up on this will clarify some of your questions as well.
When you run a migration, you will be modifying your database. The changes are viewable in the database schema (which should never be modified by hand, always modify it through migrations). This will add attributes to your models whose table you modified. In the controllers, you will add logic to deal with all of these things and the views will present the data to your users (or allow users to enter data). Asking which order is best is probably rather opinion based, but I would say you should modify the tables (run needed migrations) first. This way you can then generate the logic to deal with the new attributes. I would then create the controller logic and finally the views.
You also ask what other files need to be changed. This is heavily dependent on your system. At a base level, you should definitely be writing tests to support the logic you are generating (and many developers will advocate that you should do this before you write the other logic, a process called Test Driven Development).
TL;DR: Read the guides, work through a basic tutorial, and watch some Railscasts. This should get you up to speed on the process and best practices that go along with rails development.

Rails Active_Admin VS. my own backend

I've been thinking of writing my own backend, because I feel active_admin might not support all the requirements.
I wanted to ask if Active_Admin supports any of these just to be sure:
I have a has_and_belongs_to_many relationship between my ad model
and tag model. In the new ad page I would like to have the form for
the ads, as well as all available tags so the admin can choose which
tags to associate with the ad. I was able to do that normally in my
application, but can I do that with active_admin?
Can I add custom buttons.. Like one to convert to PDF for example,
or one to send an e-mail..
Could I add some sort of before_filter, so the admin can only view a
model, but not edit or delete it for example?
Thank you.
All of those things can be done via Active Admin, but as it was pointed out, it can be quite a nightmare actually implementing certain things depending on the amount of flexibility you need it to have. For that exact reason, I decided to start rolling my own administration panels.
I have tried an implemented almost all robust gems for admin panels. I have also sweated over several hand-made ones.
Active-Admin is very usability centred, but it is not configuration centred.
As you rightly aniticipated, some of the more complex modifications can be tedious.
In my experience, rails_admin is the best middle ground I could find.
Take a look at it, it is highly functional, completely modular (made as a Rails 3 Engine) and simpler to modify.
If you can live without some details when customizing this is definitely the way to go. However, if you need to have everything just right, then there is not substitute for hand-made.

Un-bloating models in rails 3.1

Just learning rails, developing first app and having trouble finding a straight answer to this question!
I want to keep my models as lean as possible and really only want to use them to represent objects that I might want to render in my views. Therefore, I want to remove some of the logic from one particular model and store it in a separate file. I have seen numerous guides (on this site and others) that suggest the following;
never "require" anything from inside a rails app
Store additional files in the lib folder - they used to be auto loaded in older rails releases but now you need to add an extra line in a config file to get this to happen (Example.
So I added the line, stuck the file in the lib folder, and it all worked fine. So on to the question;
I can't shake the feeling that the fact that I had to go and put some bespoke code into the config file means I'm doing this wrong (given convention over configuration). Why are people having to faff around editing configuration files to get rails to do something so basic?
Is that the best way or are there additional considerations that I'm just not seeing? Should I in fact be creating an "extras" directory rather than still sticking things in lib?
If anyone can point me in the direction of a definitive article on the matter I'd be much obliged!
There is nothing wrong with having non active record models in the model folder. If your domain is best modeled by a business logic layer and a persistence layer, then model it that way in your model folder with appropriate naming conventions. Personally I wouldn't be overly concerned with getting it perfect. Try something and see how you like it.. learn from your mistakes and keep getting better! Above all, enjoy the process.
what I do is this: keep the model logic in the model and keep the controllers as thin as possible
If there are things that should belong to your model but are somewhat distant to it (for example you have an Account model and you're working on some payments system which relates to the Account - for example you might want to call account.has_subscription?, you could use a gem called concerned_with which would split your model's main actions from others like the ones handling payments (this is just an example I recently had to take care of).

Order / Priority of development in Symfony

So I've decided after much debate and research to use symfony on my next project. To sum the project up, it is an LMS (Yes, I know there are pre-built ones such as moodle but they do not have what my particular company requires). There are many modules and issues to take into consideration. My question is in what order should one start with Symfony?
Note, the database is already made and populated with data.
The Doctrine ORM?
User Authentication?
Creating the Core modules? (Courses, Enrollment, Grades)
Page security (i.e. installing the rules for who can access what page)?
Checking out the Jobeet tutorial is good advice.
If the database is already built, I would probably do something like this:
Ensure you have a plan of what "objects" and functionality the site is to have (eg. list of courses, course detail page, course search, etc). You should be able to visualise the site and have some design mockups ready. It would also help to know whether it's going to be multi-language or not.
Generate Doctrine models & form classes on the back of your db
Create home page placeholder (probably a module) and a logged-in home page placeholder (probably a module) + basic layouts for further tweaking later.
Create signup & authentication processes (so you have the core functionality of adding users, signing them in and signing them out). Use sfDoctrineGuardPlugin.
Now, start creating core modules one by one according to your plan. As you progress, you'll notice what bits make sense as partials/components and where an additional module might make sense. Add new routing rules as you go along.
Finally, add any little bits, cleanup your template HTML/CSS, JS files, etc
... this way you have a work-in-progress site that you can play around with as you go along.
If I were you, I would try to follow this tutorial : http://www.symfony-project.org/jobeet/1_4/Doctrine/en/ You can certainly match each step of the tutorial with a feature your website has.

Does a "vertical" framework for RoR make sense?

I have been spending some time creating what I called a framework.
It was aimed at the creation of quiz likes games. It was supposed to have two players syncronized and present them a question to solve, etc.
I would like it to be fully customizable so I tried to develop components that can be put in or out of the pages. In the end the elements became slim ruby methods to add a whole bunch of Javascript and CSS to the pages.
Still the Javascript needs to connect to Ruby so methods supporting it are created but they will only be present when the component is present. Some components depend on one another making everything overly complex.
And after this attempt I wonder, is there is not a better and easier way to make a framework aimed to one kind of application on RoR? Or is the concept flawed or RoR in some way flawed?
Ruby on Rails is a framework on its own accord and is "opinionated software". This means that the writers of Rails looked at what would make most sense for creating a web application to them. Many people support the original developers views and so use Rails for their projects as well.
I think your concept of creating a quiz is a good one, but first you need to understand the rails stack. Depending on what you need exactly, you can create either an engine, plugin or whatever.
What I have seen a lot is that you specify what you need in your controller. (How you do that is up to you). All that information is stored in a class variable and transferred to the view where you can render everything you need with some helpers. The hard part is making it all generic enough to be reusable.
But, maybe Rails isn't the right tool for you. Maybe you need something more lightweight like Merb or even Sinatra.
There is no 'flaw' in Rails. Rails is not the 10**1000-in-one tool Java is. It's a framework that tries to do one way very good in a particular way. I think Rails can be the right tool for you, but you need to be skilled enough to wield the tool :)

Resources