Upcoming AjaxScaffold improvements
Posted by Richard White Sun, 16 Apr 2006 20:36:55 GMT
AjaxScaffold has been deprecated in favor of ActiveScaffold
I’ve been listening to all the feedback from the 3.0 release and come to a simple conclusion: I screwed up. I got pretty wrapped up in some parts of 3.0 and neglected to think about how “you guys” would be able to bend generated scaffolds to your will.
Case in point is my lame excuse for table data customization. Defaulting to show all the fields on a model is fine, but having the only easy option for customizing this be to defined some subset of model attributes is just weak. What about associations? belong_to, has_many and so on. And what if I’m doing single table inheritance?
Speaking of has_many and belongs_to, how can I modify the generated scaffolds to be used for creating my has_many child objects?
Fear not gentle reader (I’ve been dieing to work in the phrase ‘gentle reader’ into a post for a while now), I am currently working on a release that should make column customization much easier and more flexible. It also should make all that crusty code in _column_headings and _item a bit more readable. I currently have all the code written for what will be 3.1 and am putting it through its paces on a couple demos for associations, specifically a demo with nested scaffolds (Which is also getting some CSS love to make it look less craptacular).
I would expect everything to be released/written up in the next 48 hours.
Wow Richard, that sounds most excellent. It may not be out in time for my next demo on Tuesday, but I can’t wait to put 3.1 through its paces.
Great Richard. This is good stuff. I am working on incorporating some ajaxscaffold into a project I am working on. Things I am thinking of right now that would fit in well in the future -
1. The name of the columns coming from a database table that could store whether a column is sortable, a default width. We like this because we can create a web admin tool to customize almost all aspects of the product. 2. I don’t know if your generator has pagination but that is something that we would need in the future. There are enough examples of that we can roll our own. 3. Filtering with edit boxes below the fields. I think I saw an example of this somehwere but it was incomplete. We have it in PHP now but need to cross it over. 4. Various master detail scenarios – Most of these we will customize. 5. We are working on something to have an extra check field to select multiple rows for various db tasks (grouping, ordering and deleting). Don’t know if there is an easy way to do this in java script or just have the multiple rows.
Great work on this and just wanted to point out how we envision extending it.
Who can catch up? Man, you are fast… I did not have time to get use to new things in 3.0 and here it comes, another big feature in next 48 hours… a was just thinking about exactly those things to be added… Excellent work…
It sounds like you are on the right track with these latest ideas.
What initially drew me to your work was how simple it was for me to get something up and running and then bend it to my specific needs overtime.
With the latest release(s) I feel a bit lost in the code that is generated and therefor hesitant to use it for fear that it will take me longer to unravel it when I need to. Remember that your generator has the work ‘scaffold’ in it. By definition, it should be code that gets you moving, but is designed to be replaced overtime.
I know that all products fight with the dynamic tension of features and simplicity. I hope you will take this as one suggestion to err on the side of simplicity. I would be even more thrilled with your excellent work if you were to simply cut half of the bells and whistles.
Either way, I wish you the best of luck finding the right balance. Keep up the great work!
I have to agree with the other comments. I had some fairly straightforward pages created with mods to 2.0… I’ve come pretty close to upgrading all those pages to 3.0, and although for the most part they are ‘working’, but I definately didn’t have as clear of a sense on ‘why’ I did what I did. Keep up the great work. So far Rails is the best part of what I’m learning of Ruby and your ajax_scaffold is the best part of rails.
I am using your component as part of my application, if my client likes the demo on wensday, you can expect a well deserved donation from my part :)
Rich: Actually user stories are always very useful when trying to build something as generic as this. 1) Defining whether a column is sortable will be in 3.1, a default width will not be (though that would be easy to add, I don’t want to add in too many features unless their is a groundswell of support for them) 2) Pagination is in there as of 3.0 3) I read this as something of a quick search to filter the list results… this is probably the biggest unimplemented feature requested, but still no time table on it 4) No idea what you mean 5) Any interesting idea, I think this is something where I would prefer to do a writeup (or have someone submit one) rather than doing this out of the box since it is so project specific.
Mike: Yeah it was quite the dilemma in 3.0 as all future releases are. 2.0 was a very obvious thing for me since it grew out of a project I was working on (SlimTimer). The features in 3.0 are something a lot of people have asked for but I hadn’t used in my own projects which is probably why it suffers from not being as obvious (also the fact that a lot of client side code was moved to the server side might make things a little more difficult to grep). I am going to be very cautious and deliberate with any more features that might be added to the scaffold after this next release. It would take a groundswell of support for something, like quick search, for me to take the time to add it. I feel that the scaffold is 90% feature complete as far as the generic requirements most projects share. I’d prefer to do writeups on how to bend scaffolds to do specific jobs than include extra features in the generator.
Dean: The last comment to Mike could be addressed to you as well. Feel free to email me if you have any questions (or better yet put them on the forum). I plan to cherry pick from the questions I get for future articles.
Abdur-Rahman: Wonderful, hope it all goes well.
I’ve played some with your ajax_scaffold. First off, nice work.
Now onto my “userstory” ;) .. What made me skip ajax_scaffold when building a webadmin now was the fact that the scaffold is very hard to upgrade once you’ve tailored it into your own special needs? Yes, maybe that’s exaclty what scaffolds are about… but with as many features as you have in ajax_scaffold it doesn’t feel like “throw away code” anymore. (especially not after some hardwork modding)
Seems like others had the same experience when going from 2.0 to 3.0.. but I guess it’s as true for 3.0.0 -> 3.x?
What can I muck around with (filewise) and what should I leave alone If I want to be able to upgrade to the next release?
Im about to build automatic dropdownboxes for belongs_to-IDs. relations into my admin since entering xxx_id by number isn’t much fun.
As I got it, this is something you’ve thought about too, is this planned for the 3.1-release? Or at all?
Thought of making a rails-engine out of this instead of a scaffold? .. I think it could solve some of the extend-but-continue-to-upgrade-problems I’ve mentioned.. but probably far from a magic bullet :).
Looking forward to check out 3.1 when it’s released.
hum, somebody ate my newlines, hopefully you can read my above text without straining your eyes too much ;)
To add loading indicator to page numbers:
In ajax_scaffold_helper.rb replace with this: def pagination_ajax_links(paginator, params, indicator_params) pagination_links_each(paginator, {}) do |n| link_to_remote n, { :url => params.merge(:page => n ), :loading => “Element.show(’#{loading_indicator_id(indicator_params)}’);”, :update => scaffold_content_id(params) }, { :href => url_for(params.merge(:page => n )) } end end
In each _pagination_links.rhtml replace the line with: <%= pagination_ajax_links @paginator, pagination_params, indicator_params %>
and in your
Slain: That should be fixed in 3.1
Richard, thanks for the reply and all the hard work on the this new release. I feel like I must make one last ditch effort to help on the exploding complexity front. Please forgive me if I seem out of line…I am just trying to help! This time I would like to address everyone that is requesting features. STOP DOING IT! The name of this wonderful (at least in version 2) piece of code says it all…’scaffold’. It should NOT be solving all your problems for you. It should be designed to get things up and running. Things have gotten way out of hand. I can’t even come close to updating the code in it’s current state. It also might bereasonable to ask if editing these 1-many relationships is really something that is best solved by this ajaxified solution. My personal test for using this over standard scaffold was ‘simplicity of model’. If it was a complicated model, why not just nav to a dedicated page? I realize that everyone has different needs an desires, but the things that are most successful are those that do one things very well and I for one was thrilled with version 2. I am currently looking for a way to downgrade to that version so I can keep on smiling about everything that it enabled me to do. :)
I’m with Mike on this one! Although I won’t go back to 2.0, I think 3.0 is pretty darn close to perfect! - I’ve added a filter to those pages that I want (with a partial and about 4 lines of controller code), and think that now the best thing would be for more articles on how to extend the scaffold, not a bunch of more code on autogenerating features.
Mike & Dean: I don’t plan on adding any more features to the scaffold. I feel that 3.1 is exactly where I want to be and I’d probably focus more on either releasing plugins or rolling out an ajax scaffold plugin. The additions to 3.1 (Dunno if you posted this before or after I released it) are mainly refactoring some of the parts of the code that imho were hard to grep and customize.