Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

re-usable css/js framework for admin interface #139

Open
gerrit opened this Issue Aug 9, 2010 · 9 comments

Comments

Projects
None yet
4 participants
Member

gerrit commented Aug 9, 2010

I've recently had to adjust the admin interface of a few extensions to fit the new admin interface from 0.9.

This turned out to be quite repetetive and hacky. One extension e.g. needed a tab-control similar to the main page edit area. Because the CSS & JS that comes with radiant is overly specific (uses ID selectors for instance) I had to basically copy&paste the entire JS&CSS for this functionality. Of course, next time Radiant makes even a tiny colour change I'll have to adjust. Other examples of this are tables & floating popups.

It would be great if Radiant had some sort of documented html/css/js framework that extensions can use so they fit in to radiant automatically. Apart from ensuring visual consistency, this would make writing admin interfaces for extensions a whole lot easier and faster.

Ideally there would also be helper methods to generate the appropriate markup. The javascript hooks can probably all be done unobtrusively.

Basically, just changing the CSS a little bit would already be a huge benefit for extension authors.

If anyone else thinks this is a good idea I'm quite willing to have a go at this.

Member

mislav commented Aug 9, 2010

We were discussing this recently and core members generally agreed that our stylesheets are part of the Radiant "framework" (if you can call it that) and that we should make them more extensible.

We would welcome changes in the lines of what you suggested here. Anything that enables you to write your extensions with less code would be a welcome improvement.

Owner

jlong commented Aug 9, 2010

Yup, as Mislav, said we are working on this. Please fork the Radiant prototype and have a go at it.

Member

gerrit commented Aug 9, 2010

Why the prototype? I'd have done it in radiant proper because that allows me to test it in conjunction /w installed extensions.

Member

gerrit commented Aug 9, 2010

oops. didn't mean to actually “close” the issue, any way to re-open it?

Owner

jlong commented Aug 9, 2010

The prototype is where we are working on new CSS and markup for the admin UI. If you update the app those changes will have to be merged back into the prototype. In general stylesheet and javascript development takes place in the prototype and is copied over into the main application as needed.

Member

mislav commented Aug 9, 2010

Just reopened the issue via the API.

jlong: we get the workflow with the prototype, but you have to understand that going through the prototype phase complicates things for gerrit in this case. Why not do it against radiant master and then port it over to the prototype?

Owner

jlong commented Aug 9, 2010

Why does it complicate things? There is an example extension in the prototype (Acme) that can be used to work out and document generic markup.

Also there are recent changes in the CSS in the prototype that have not made it into the app yet.

Owner

saturnflyer commented Aug 9, 2010

It does complicate things in that it is an entirely different setup. Rails helpers, for example, don't exist in the prototype and the Haml code is different because of this. I'm still wary of changing things, because I'd rather see arguments about html/css done outside the main repository at the moment.

If what we're doing is fixing or updating existing styles, then back-porting to the prototype is fine with me. But creating new things should probably be done first in the prototype. The exception for this, of course, is helpers which generate code.

gerrit, if you want to tackle this, take a look at the prototype as well, but make your changes in a non-master branch of radiant and we can all take a look at it to work with you.

Owner

jlong commented Aug 9, 2010

gerrit, saturnflyer and I just spent some time hashing through this. We're not trying to make it difficult to contribute, so we will leave it to you as to how you want to do that. You could fork either the app or the prototype, or both.

The issue is that if you are making changes to helpers, you should probably do that in the app. But if you are making changes to styles and javascripts it would be better to do that first in the prototype.

Since you are making changes to both in this case it sounds like you may be faced with a bit of a chicken or egg problem (which is why we will leave it to your judgement). If you can, I'd suggest that you break it down into two iterations:

  1. Work out the styles and javascripts that would be appropriate in the prototype. Flesh out the Acme extension so that new generic styles are well documented. Then get feedback from the core team.
  2. Work on custom helpers to generate styles in the app (note that the prototype also supports helpers, so you could work on that there, but it may be more difficult if you plan to implement your own form_for helpers, etc...)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment