View-refactoring question

[grimen]

I asked about HAML before so won't go into that any further, but I
wonder if any of you been looking into Formtastic? I feel my fingers
itching when I see the Spree views (not the worst I've seen, but not
definitely not acceptable in an awesome project like Spree and on
Rails). There are no drawbacks with using Formtastic what so ever, in
compare to HAML where developers need to learn a new syntax. Also a
lot of the Spree views I looked into are not valid XHTML. I did a
refactoring-experiment to show-n-prove:

Before:
http://pastie.org/533978

After:
http://pastie.org/533977

After my Formtastic-I18n-patch is merged (very soon):
http://pastie.org/533981

I'm a bit tempted to take care of this refactoring. The question is,
would this be appreciated? I see a winning in less potential bugs,
more maintainable app, cleaner views, valid HTML, less CSS with better
outcome in today's browsers, etc.


Formtastic: http://github.com/justinfrench/formtastic


grimen

[Sean Schofield]

Grimen,

First of all you did the right thing in posting here to spree-user
before doing a lot of work. I'm renaming the subject and adding
[proposal] since this is a proposal to make a major change to all of
the views and I want to make sure it gets noticed.

Formtastic looks interesting. I've never hear of it before but your
pastie examples are compelling (thanks for taking the time to write
those up.) I'm not sure that I see less bugs with this approach but
definitely cleaner views.

I could see this causing some confusion with designers who don't
understand the DSL underlying this. It would also be another hurdle
to overcome in order to be able to override the views yourself ("how
is this label being generated?", etc.) On the other hand, there is
precedent for this (resource_controller jumps to mind.)

So I guess I'm open to the idea but need some more time to mull it
over. I'd also be curious to hear what others have to say.

Sean

[grimen]

OK, thanks for the clear response Sean. Take your times, I'll stay
tuned here for months anyway - just got started with Spree. =)

grimen

[mwlang88]

> I could see this causing some confusion with designers who don't
> understand the DSL underlying this.  It would also be another hurdle
> to overcome in order to be able to override the views yourself ("how
> is this label being generated?", etc.)  On the other hand, there is
> precedent for this (resource_controller jumps to mind.)
>

Do designers really care that much how the final HTML gets generated?
With my designer hat on, I just wanted to know what the CSS selectors
were so I could style the various elements emitted via the views. To
this end, I simply stripped out all the *.css and images folder and
started with as blank of a slate as possible and moved forward with
firebug inspections iteratively until I gathered everything into my
new *.css files.

In my first pass through on implementing my client's site, I found
myself stripping out clutter from the various views and simplifying
them to emit simple structures with a class or id selector added in so
I could style it. I also found myself pushing various business logic
out of the views and into my models (such as not showing empty
taxon's, determining whether an item was in stock and available to
purchase or not, and so on).

I also found myself pushing business logic that was in the view down
to the model. I posted two or three tickets as I encountered
scenarios, but admittedly, ended up blazing through the views just to
get the store up and operational. I think if we're going to look at
the views as they are now and where we want them to be tomorrow, there
are a few principles to follow:

1) Business logic in the model, not the view. Aside from uncluttering
the views, if we need to optimize the logic, we can do so in the model
without fear we're breaking the views (unless we're deliberately
deprecating some public method on that model...).

2) Clean, simple XHTML compliant views that emit semantic ID and CLASS
tags to provide designers easy means of selecting and changing styling
and layout.

Plus some questions to answer:

1) What is going to be the best practice for overriding views? (a
gemmed spree with extensions/site seems to be a reasonable approach).

2) What about for simple extension of the views? (for example, the
new checkout's system of charges approach...how would I hook in to add
my new coupon credits or "heavy item" shipping charges?...Do I
*really* have to override the entire view just to slip another line
item in?). Perhaps before/after hooks to pick up additional partials?

Sorry, these ain't answers, per se, but certainly, but certainly some
thoughts that are presently in the back of my mind.

Michael

[Sean Schofield]

> 1) Business logic in the model, not the view.  Aside from uncluttering
> the views, if we need to optimize the logic, we can do so in the model
> without fear we're breaking the views (unless we're deliberately
> deprecating some public method on that model...).

Absolutely. Any tickets/patches you want to provide on this are
welcome. Nothing controversial about that and a series of "small"
improvements can be quite helpful when summed together.

> 2) Clean, simple XHTML compliant views that emit semantic ID and CLASS
> tags to provide designers easy means of selecting and changing styling
> and layout.

Simple XHTML is fine (no argument there.) The only part I'm not sure
I can commit to (yet) is the mini "form language" for building the
forms. Is there a way we can work towards this goal without
committing to Formtastic? I'd like to hold off on that decision if
possible.

>
> Plus some questions to answer:
>
> 1) What is going to be the best practice for overriding views? (a
> gemmed spree with extensions/site seems to be a reasonable approach).

Yes this is the recommended approach. We're trying to build up our
docs (tips & tricks, etc. in documentation) to provide suggest ways of
customizing so as to minimize your "pain" in upgrading, etc.

> 2) What about for simple extension of the views?  (for example, the
> new checkout's system of charges approach...how would I hook in to add
> my new coupon credits or "heavy item" shipping charges?...Do I
> *really* have to override the entire view just to slip another line
> item in?).  Perhaps before/after hooks to pick up additional partials?

I don't imagine having to customize the views 100%. We've already
broken the checkout views down into reasonable chunks (at least
compared to before.) I think we can already show an arbitrary number
of charges in the checkout view (although maybe i'm confused on that.)
We also have quite a bit of flexibility in adding/removing steps in
the checkout process.

> Sorry, these ain't answers, per se, but certainly, but certainly some
> thoughts that are presently in the back of my mind.

Well there's certainly room for improvement. The more Spree sites we
build the more ideas we will have on how to make it easier for real
world apps the next time. Really the next 4-5 months will be focused
on this and rounding out the basic feature set.

> Michael

Sean