Last week I had a very interesting discussion with Wynn from Squeejee[1]. His team is working on a large scale Spree project and they were coming up with some ideas on how to make Spree easier to customize for developers. We were also talking about how the non-admin stuff is really just a starting point for what you could do with your custom site. I've thought about this for a while now and its a subject that has been raised more then once on this list.
We eventually started discussing the possibility of turning the front end into something that would support a template system and would ultimately be more designer friendly. One idea was to move all of the views and helpers for the front end stuff into a default template. So the default template would be what you see now on the default install but it would then be possible to develop and deploy your own template without having to override specific partials, etc.
This is a ways off from actually happening but Wynn suggested I throw the topic out here on spree-user to get a discussion going.
Since we already have extensions system, we could probably separate view specific stuff into separate extension to show where is the best line to cut, when you create your site extension, and only thing you want to change is layout.
Yes, that would be very nice. I'm running into some issues now where my
partner wants some changes made for certain types of products that I'm not
really sure how to do. We have collections of products, and based on
questions that need to be asked certain items and certain quantities of
items need to be selected, and then the customer given a chance to select
variants (upgrades, etc) of those items. I'm just about to get started
figuring out how I'm going to code this request, since not every item needs
this, just the package type items.
Carl
On Sun, Aug 16, 2009 at 11:16 PM, Marcin Raczkowski <mailing...@gmail.com>wrote:
> Since we already have extensions system, we could probably separate view
> specific stuff into separate extension to show where is the best line to
> cut, when you create your site extension, and only thing you want to
> change is layout.
+1
it'd be great to have this bundled into one simple location.
one thing to watch out though (IMHO, as a new participant on the
list), is avoid making the template management overly complicated.
I've used Mephisto for a quite a while... it has a themes system built
on top of the Liquid templating engine. all very nice, only nobody is
really creating themes for Mephisto after the first ones made a coule
of years back, and the people editing templates are at least good
enough developers to not need the protection Liquid provides - and to
find extending the built-in tags and filters a royal hassle since
there's nobody really needing them (on top of being a PITA to debug).
I find myself wanting to tear-off the templating system everytime I
try to customize the front-end... plain-old erb templates with
action-view helpers would be way better. Developers would have an
easier time to customize it, and designers or htmlers would just deal
with simple and familiar variables + loops - instead of learning
liquid syntax.
> Yes, that would be very nice. I'm running into some issues now where my
> partner wants some changes made for certain types of products that I'm not
> really sure how to do. We have collections of products, and based on
> questions that need to be asked certain items and certain quantities of
> items need to be selected, and then the customer given a chance to select
> variants (upgrades, etc) of those items. I'm just about to get started
> figuring out how I'm going to code this request, since not every item needs
> this, just the package type items.
> Carl
> On Sun, Aug 16, 2009 at 11:16 PM, Marcin Raczkowski <mailing...@gmail.com>
> wrote:
>> Great Idea!
>> Since we already have extensions system, we could probably separate view
>> specific stuff into separate extension to show where is the best line to
>> cut, when you create your site extension, and only thing you want to
>> change is layout.
> +1
> it'd be great to have this bundled into one simple location.
> one thing to watch out though (IMHO, as a new participant on the
> list), is avoid making the template management overly complicated.
> I've used Mephisto for a quite a while... it has a themes system built
> on top of the Liquid templating engine. all very nice, only nobody is
> really creating themes for Mephisto after the first ones made a coule
> of years back, and the people editing templates are at least good
> enough developers to not need the protection Liquid provides - and to
> find extending the built-in tags and filters a royal hassle since
> there's nobody really needing them (on top of being a PITA to debug).
> I find myself wanting to tear-off the templating system everytime I
> try to customize the front-end... plain-old erb templates with
> action-view helpers would be way better. Developers would have an
> easier time to customize it, and designers or htmlers would just deal
> with simple and familiar variables + loops - instead of learning
> liquid syntax.
> > Yes, that would be very nice. I'm running into some issues now where my
> > partner wants some changes made for certain types of products that I'm not
> > really sure how to do. We have collections of products, and based on
> > questions that need to be asked certain items and certain quantities of
> > items need to be selected, and then the customer given a chance to select
> > variants (upgrades, etc) of those items. I'm just about to get started
> > figuring out how I'm going to code this request, since not every item needs
> > this, just the package type items.
> > Carl
> > On Sun, Aug 16, 2009 at 11:16 PM, Marcin Raczkowski <mailing...@gmail.com>
> > wrote:
> >> Great Idea!
> >> Since we already have extensions system, we could probably separate view
> >> specific stuff into separate extension to show where is the best line to
> >> cut, when you create your site extension, and only thing you want to
> >> change is layout.
Totally agree with this one, ecommerce is a bigger divergence that
almost always requires more customization than theming. So don't make
theming easy at the expense of raw ERB customizations. Keep the ERB
templates separated into a container is a great idea though.
Tim
On Aug 17, 2009, at 11:45 AM, Oliver Barnes wrote:
> +1
> it'd be great to have this bundled into one simple location.
> one thing to watch out though (IMHO, as a new participant on the
> list), is avoid making the template management overly complicated.
> I've used Mephisto for a quite a while... it has a themes system built
> on top of the Liquid templating engine. all very nice, only nobody is
> really creating themes for Mephisto after the first ones made a coule
> of years back, and the people editing templates are at least good
> enough developers to not need the protection Liquid provides - and to
> find extending the built-in tags and filters a royal hassle since
> there's nobody really needing them (on top of being a PITA to debug).
> I find myself wanting to tear-off the templating system everytime I
> try to customize the front-end... plain-old erb templates with
> action-view helpers would be way better. Developers would have an
> easier time to customize it, and designers or htmlers would just deal
> with simple and familiar variables + loops - instead of learning
> liquid syntax.
> 2009/8/17 Carl Anderson <nexus...@gmail.com>:
>> Yes, that would be very nice. I'm running into some issues now
>> where my
>> partner wants some changes made for certain types of products that
>> I'm not
>> really sure how to do. We have collections of products, and based on
>> questions that need to be asked certain items and certain
>> quantities of
>> items need to be selected, and then the customer given a chance to
>> select
>> variants (upgrades, etc) of those items. I'm just about to get
>> started
>> figuring out how I'm going to code this request, since not every
>> item needs
>> this, just the package type items.
>> Carl
>> On Sun, Aug 16, 2009 at 11:16 PM, Marcin Raczkowski <mailing...@gmail.com
>> wrote:
>>> Great Idea!
>>> Since we already have extensions system, we could probably
>>> separate view
>>> specific stuff into separate extension to show where is the best
>>> line to
>>> cut, when you create your site extension, and only thing you want to
>>> change is layout.
> Wordpress has a successful themes ecosystem, is there anything Spree > can learn from Wordpress here?
Wordpress was specifically mentioned in our discussion. I think Wordpress has a lot of functionality that should be looked at very closely. eCommerce is much more complicated then blogging but we should borrow their ideas where they make sense.
By the way, one of the outcomes for this would be that it would be easier for people wanting to develop in HAML. Assuming we had the volunteers to maintain, we'd create two default templates, one in ERB and one in HAML.
I agree that we should not add any "easy" templating engine, providing 2 "reference" templates with erb / haml is probably best idea. Especially, since If we prepare on in haml we could simply compile it into erb AFAIK.
...Wordpress serves as an example
-- a simple wordpress theme contains ~10 views. The views can be edited
to use existing functionality that comes with an out of the box
wordpress install.
I think Spree could succeed similarly -- the set of rails views are
always going to be overridden for a client and would require snippets to
be added for the existing out of the box functionality (reviews,
wishlist, etc). A Spree theme could also contain a set of views that
correspond to user account or landing page functionality and these views
can be included or excluded from the client theme. So, out of the box
Spree functionality could be impressive, but the themes that use the out
of the box functionality may range from simple to extensive. ...
Sean Schofield wrote:
>> Wordpress has a successful themes ecosystem, is there anything Spree
>> can learn from Wordpress here?
> Wordpress was specifically mentioned in our discussion. I think
> Wordpress has a lot of functionality that should be looked at very
> closely. eCommerce is much more complicated then blogging but we
> should borrow their ideas where they make sense.
> By the way, one of the outcomes for this would be that it would be
> easier for people wanting to develop in HAML. Assuming we had the
> volunteers to maintain, we'd create two default templates, one in ERB
> and one in HAML.