>
Hey,
I have read thorugh your ideas and I must say it looks really impressive.
I'd like to point out a few things. For a developer the most important thing is to
have a strict guide how to use certain website elements and blocks. Strictly given
structure of application elements are really important to keep application layout
consistent. So we should have given library of "small" elements (buttons,
pagination, headers, lists, tables...) and "layout level structures" like
content sections, tab-containers... With these, abiding the haml structure is as important
as actual styling of the elements. Haml structure is the actual thing that everyone of us
creates, so there must be strictly given what is the page and elements structure through
the app.
So the haml of a view should be constrained to its respective parent. The view name and
the parent #ID of here it exists should be the same to make this easy. On the shell/chrome
level the parent haml and sub views are known. Beyond that we get a little tricky with
having to check that a view applies to the session or has been requested.
I'm still working on some demo haml to illustrate the higher up haml structure of
where our views fit in but if you're online I can ping you with more specific info.
I'll need help with things like how we implement global and per-user caching and
weighing up what things are too expensive to do by default. (hoping to catch Scott
sometime this week for a sanity check of ideas)
The css part is often developed by far less people ( but one person is definitely not
enough ), its also important to have a unified style pieces too, which is quite easily
maintained by mixins.
As mentioned there will still be style rules allocated to functional components
but I understand that we need to document this further for each context.
Using view anchors (#something) in urls is nice idea which works nice
in rails routes by specifiing :anchor
(
http://lists.rubyonrails.org/pipermail/rails/2006-June/046488.html).
Yes I am aware it was possible :-). Whole page requests are very very
disrespectful of the client if they aren't absolutely needed.. Not doing this with
sane caching and ajaxing expensive requests might fix up a lot of our stuff.
Andy how would you like to strucure the css? I would like to see you
opinion on this. I mean how would the actual scss files organize? How would we implement
various features in it? The way it is now or some other way?
All sass to be rendered into style.css
This means all views, layout chrome and components are loaded with the initial hit.
There is no reason why our CSS should be so expensive as to make this a problem.
As for the scss file layout, I imagine it would resemble something like this :
Layout Chrome
Globals (including widgets)
Views-global (user views etc)
Views-monitor
Views-admin
Views-*..... Etc
Media rules
And be rendered in that hierarchy down to style.css
From my point of view the actual styling is not that important (It can be quite easily
changed) but what I find really important is unifiing features and elements structures
through the application (haml stuff basicly) which is not so easy to change during the
time and can base this work on what we have now. Having library of haml templates of
various features would greatly help I think.
I totally understand. I'm putting a draft haml structure together.
the layout/component/views parts are easy, right now I'm still wrangling system global
changes and other small things like status notification.
I would really like to see the structural changes you propose in our
app.
Me too :-) remember, it's going to be a mock-draft but I hope it will be useful
Thanks for your reply!