Hi,

I'm building a custom set of views with HAML, through various glitches I've
been hit with, I decided to disable Deface. It's got it's ups and downs...

For
- existing overrides don't screw with my new views
- new plugins are only implemented visually how and when I decide
- updates to plugins don't affect my views (reduces *visual* testing
overheads)

Against
- admin interface restricted to 'day zero'
- have to manually rebuild the admin interface to incorporate overrides
- updates generally bring in more changes to admin views then those for the
front end, so Deface would be useful
- would be useful to Deface my own work or the admin for temporary patches
etc

So, I suppose the big question, is whether I can specify only a specific
path for Deface files? Being able to Deface my own views is purely optional
and not required unless it's possible with little effort.

How would I Restrict Deface to only files in the path structure:
*/app/overrides/admin

If I change the base Deface path, then it's going to change the relative
path relationship between the Deface files and the views they're patching,
or can I specify both the Deface file location and the target files
separately (therefore accounting for only processing Defaces located in the
admin directories).

And, which actions do I need to re-eval to override this?

In being thorough, I'm using the views and overrides of all of the core and
plugin gems as a starting point in developing my new views, so I'm not
missing anything out as I work through it. It also leads to a second
question, but I'll post that separately as it's related to Taxonomies.

Regards
Jon

--
You received this message because you are subscribed to the Google Groups "Spree" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Brian Quinn at Feb 21, 2013 at 5:02 pm
    Hey Jon,
    I like that term "visual testing overhead" - its been something that I've been thinking about for a while with regards to Deface. Stuff can just look different and not necessarily break in a way a spec could determine. It's a really interesting problem, and something I've got an idea on how to solve.

    So to answer your question, I think with a little Deface hack you could only allow admin overrides, here's how:

    Deface maintains a list of all the overrides loaded, accessible in Rails.application.config.deface.overrides.all , it's hash who's key is the virtual_path for the target view, see:

    1.9.3-p327 :007 > Rails.application.config.deface.overrides.all.keys
    => [:"spree/admin/users/edit", :"spree/layouts/spree_application", :"spree/admin/shared/_configuration_menu", :"spree/layouts/admin", :"spree/shared/_nav_bar", :"spree/checkout/registration"]



    You can just remove the keys that do not start with "spree/admin" and you should be good to go! Note the keys are symbols.

    I'm not 100% sure where the best place to do this is, but possibly in an initializer, you'll have to test a few options there. The problem being: will Deface have loaded all the overrides before the initializer loads ( Rails initialization process still confounds me).

    Hope that helps,

    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com

    On Thursday 21 February 2013 at 16:31, Jon McCoy wrote:

    Hi,

    I'm building a custom set of views with HAML, through various glitches I've been hit with, I decided to disable Deface. It's got it's ups and downs...

    For
    - existing overrides don't screw with my new views
    - new plugins are only implemented visually how and when I decide
    - updates to plugins don't affect my views (reduces *visual* testing overheads)

    Against
    - admin interface restricted to 'day zero'
    - have to manually rebuild the admin interface to incorporate overrides
    - updates generally bring in more changes to admin views then those for the front end, so Deface would be useful
    - would be useful to Deface my own work or the admin for temporary patches etc

    So, I suppose the big question, is whether I can specify only a specific path for Deface files? Being able to Deface my own views is purely optional and not required unless it's possible with little effort.

    How would I Restrict Deface to only files in the path structure: */app/overrides/admin

    If I change the base Deface path, then it's going to change the relative path relationship between the Deface files and the views they're patching, or can I specify both the Deface file location and the target files separately (therefore accounting for only processing Defaces located in the admin directories).

    And, which actions do I need to re-eval to override this?

    In being thorough, I'm using the views and overrides of all of the core and plugin gems as a starting point in developing my new views, so I'm not missing anything out as I work through it. It also leads to a second question, but I'll post that separately as it's related to Taxonomies.

    Regards
    Jon
    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com (mailto:spree-user+unsubscribe@googlegroups.com).
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jon McCoy at Feb 21, 2013 at 9:07 pm
    Hi Brian,

    As nice as Deface is, I do feel that for front ends that are being restyled
    or modified that it can cause bigger problems than it solves. For admin
    interfaces and structured interfaces (ie a CRM system etc) where the style
    isn't being changed by end users (other than perhaps changing logos or
    background colours) then Deface is perfect and I wish it had been around
    longer than it has - I'd have had countless uses for it by now. But, for
    interfaces that the end user is expected to change visually (either by CSS
    or changing views) then I think you run risk of breaking visual flow. As
    you say, a big visual change is unlikely to break a spec...

    Anyway, thanks for your pointers, they've helped me solve my problem.

    Finding the right place was the difficult part as you say, I don't profess
    to understand Rail's inner architecture. The config hash is available in
    three places, depending on where you're in the stack at the time which
    doesn't help either (I can only wildly guess at the inheritance).

    Rails.application.config.deface.overrides
    Rails.configuration.deface.overrides
    Store::Application.config.deface.overrides

    It would seem that config/initializers/* loads too early, before require
    has been call for the Deface overrides. Similarly, with
    config/application.rb and config/environments/* it's loading too early.

    Then I spotted the config.prepare_to block in config/application.rb and
    where both decorators and overrides are loaded. Adding the following line
    after the overrides section seems to have the desired effect:

    module Store
    class Application < Rails::Application

    config.to_prepare do
    # Load application's model / class decorators
    Dir.glob(File.join(File.dirname(__FILE__), "../app/**/*_decorator*.rb"
    )) do |c|
    Rails.configuration.cache_classes ? require(c) : load(c)
    end

    # Load application's view overrides
    Dir.glob(File.join(File.dirname(__FILE__), "../app/overrides/*.rb"))
    do |c|
    Rails.configuration.cache_classes ? require(c) : load(c)
    end
    Rails.configuration.deface.overrides.all.delete_if {|key,value| !key.
    to_s.start_with?('spree/admin') }
    end

    ...

    end
    end




    On Thursday, February 21, 2013 5:02:49 PM UTC, Brian Quinn wrote:

    Hey Jon,
    I like that term "visual testing overhead" - its been something that I've
    been thinking about for a while with regards to Deface. Stuff can just look
    different and not necessarily break in a way a spec could determine. It's a
    really interesting problem, and something I've got an idea on how to solve.

    So to answer your question, I think with a little Deface hack you could
    only allow admin overrides, here's how:

    Deface maintains a list of all the overrides loaded, accessible in Rails.
    application.config.deface.overrides.all , it's hash who's key is the
    virtual_path for the target view, see:

    1.9.3-p327 :007 > Rails.application.config.deface.overrides.all.keys
    => [:"spree/admin/users/edit", :"spree/layouts/spree_application",
    :"spree/admin/shared/_configuration_menu", :"spree/layouts/admin",
    :"spree/shared/_nav_bar", :"spree/checkout/registration"]

    You can just remove the keys that do not start with "spree/admin" and you
    should be good to go! Note the keys are symbols.

    I'm not 100% sure where the best place to do this is, but possibly in an
    initializer, you'll have to test a few options there. The problem being:
    will Deface have loaded all the overrides before the initializer loads (
    Rails initialization process still confounds me).

    Hope that helps,

    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com

    On Thursday 21 February 2013 at 16:31, Jon McCoy wrote:

    Hi,

    I'm building a custom set of views with HAML, through various glitches
    I've been hit with, I decided to disable Deface. It's got it's ups and
    downs...

    For
    - existing overrides don't screw with my new views
    - new plugins are only implemented visually how and when I decide
    - updates to plugins don't affect my views (reduces *visual* testing
    overheads)

    Against
    - admin interface restricted to 'day zero'
    - have to manually rebuild the admin interface to incorporate overrides
    - updates generally bring in more changes to admin views then those for
    the front end, so Deface would be useful
    - would be useful to Deface my own work or the admin for temporary patches
    etc

    So, I suppose the big question, is whether I can specify only a specific
    path for Deface files? Being able to Deface my own views is purely optional
    and not required unless it's possible with little effort.

    How would I Restrict Deface to only files in the path structure:
    */app/overrides/admin

    If I change the base Deface path, then it's going to change the relative
    path relationship between the Deface files and the views they're patching,
    or can I specify both the Deface file location and the target files
    separately (therefore accounting for only processing Defaces located in the
    admin directories).

    And, which actions do I need to re-eval to override this?

    In being thorough, I'm using the views and overrides of all of the core
    and plugin gems as a starting point in developing my new views, so I'm not
    missing anything out as I work through it. It also leads to a second
    question, but I'll post that separately as it's related to Taxonomies.

    Regards
    Jon

    --
    You received this message because you are subscribed to the Google Groups
    "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to spree-user+...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.



    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jon McCoy at Feb 21, 2013 at 9:28 pm
    I Should also add, it appears that's the loading of *local* overrides, but
    given that those will be loaded after overrides that any gems may be
    bringing into the mix, it's having the net effect.

    I am a little concerned though, because the override import explicitly
    references "../app/overrides/*.rb", which means that somewhere else, some
    other magic is importing the .html.erb.deface files I have in the mirrored
    folder structure (I setup some test Defaces using this method).

    So, if I moved my line before the local overrides are imported, then
    provided I only used *.rb overrides, then I'll be expunging all Deface
    patches minus the spree/admin ones and *then* I'd be importing my local
    overrides. But, if I used the .html.erb.deface approach, they're already
    loaded and get expunged with those from gems too... :-/

    Order:

    config/boot.rb -> "~/.bundler/ruby/1.8/*/app/overrides/*.rb"
    ?? -> "../app/overrides/*/*.html.erb.deface
    config/application.rb -> "../app/overrides/*.rb"

    Hope this makes sense!

    Jon


    On Thursday, February 21, 2013 9:07:07 PM UTC, Jon McCoy wrote:

    Hi Brian,

    As nice as Deface is, I do feel that for front ends that are being
    restyled or modified that it can cause bigger problems than it solves. For
    admin interfaces and structured interfaces (ie a CRM system etc) where the
    style isn't being changed by end users (other than perhaps changing logos
    or background colours) then Deface is perfect and I wish it had been around
    longer than it has - I'd have had countless uses for it by now. But, for
    interfaces that the end user is expected to change visually (either by CSS
    or changing views) then I think you run risk of breaking visual flow. As
    you say, a big visual change is unlikely to break a spec...

    Anyway, thanks for your pointers, they've helped me solve my problem.

    Finding the right place was the difficult part as you say, I don't profess
    to understand Rail's inner architecture. The config hash is available in
    three places, depending on where you're in the stack at the time which
    doesn't help either (I can only wildly guess at the inheritance).

    Rails.application.config.deface.overrides
    Rails.configuration.deface.overrides
    Store::Application.config.deface.overrides

    It would seem that config/initializers/* loads too early, before require
    has been call for the Deface overrides. Similarly, with
    config/application.rb and config/environments/* it's loading too early.

    Then I spotted the config.prepare_to block in config/application.rb and
    where both decorators and overrides are loaded. Adding the following line
    after the overrides section seems to have the desired effect:

    module Store
    class Application < Rails::Application

    config.to_prepare do
    # Load application's model / class decorators
    Dir.glob(File.join(File.dirname(__FILE__),
    "../app/**/*_decorator*.rb")) do |c|
    Rails.configuration.cache_classes ? require(c) : load(c)
    end

    # Load application's view overrides
    Dir.glob(File.join(File.dirname(__FILE__), "../app/overrides/*.rb"))
    do |c|
    Rails.configuration.cache_classes ? require(c) : load(c)
    end
    Rails.configuration.deface.overrides.all.delete_if {|key,value| !key
    .to_s.start_with?('spree/admin') }
    end

    ...

    end
    end




    On Thursday, February 21, 2013 5:02:49 PM UTC, Brian Quinn wrote:

    Hey Jon,
    I like that term "visual testing overhead" - its been something that I've
    been thinking about for a while with regards to Deface. Stuff can just look
    different and not necessarily break in a way a spec could determine. It's a
    really interesting problem, and something I've got an idea on how to solve.

    So to answer your question, I think with a little Deface hack you could
    only allow admin overrides, here's how:

    Deface maintains a list of all the overrides loaded, accessible in Rails.
    application.config.deface.overrides.all , it's hash who's key is the
    virtual_path for the target view, see:

    1.9.3-p327 :007 > Rails.application.config.deface.overrides.all.keys
    => [:"spree/admin/users/edit", :"spree/layouts/spree_application",
    :"spree/admin/shared/_configuration_menu", :"spree/layouts/admin",
    :"spree/shared/_nav_bar", :"spree/checkout/registration"]

    You can just remove the keys that do not start with "spree/admin" and you
    should be good to go! Note the keys are symbols.

    I'm not 100% sure where the best place to do this is, but possibly in an
    initializer, you'll have to test a few options there. The problem being:
    will Deface have loaded all the overrides before the initializer loads (
    Rails initialization process still confounds me).

    Hope that helps,

    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com

    On Thursday 21 February 2013 at 16:31, Jon McCoy wrote:

    Hi,

    I'm building a custom set of views with HAML, through various glitches
    I've been hit with, I decided to disable Deface. It's got it's ups and
    downs...

    For
    - existing overrides don't screw with my new views
    - new plugins are only implemented visually how and when I decide
    - updates to plugins don't affect my views (reduces *visual* testing
    overheads)

    Against
    - admin interface restricted to 'day zero'
    - have to manually rebuild the admin interface to incorporate overrides
    - updates generally bring in more changes to admin views then those for
    the front end, so Deface would be useful
    - would be useful to Deface my own work or the admin for temporary
    patches etc

    So, I suppose the big question, is whether I can specify only a specific
    path for Deface files? Being able to Deface my own views is purely optional
    and not required unless it's possible with little effort.

    How would I Restrict Deface to only files in the path structure:
    */app/overrides/admin

    If I change the base Deface path, then it's going to change the relative
    path relationship between the Deface files and the views they're patching,
    or can I specify both the Deface file location and the target files
    separately (therefore accounting for only processing Defaces located in the
    admin directories).

    And, which actions do I need to re-eval to override this?

    In being thorough, I'm using the views and overrides of all of the core
    and plugin gems as a starting point in developing my new views, so I'm not
    missing anything out as I work through it. It also leads to a second
    question, but I'll post that separately as it's related to Taxonomies.

    Regards
    Jon

    --
    You received this message because you are subscribed to the Google Groups
    "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to spree-user+...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.



    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brian Quinn at Feb 21, 2013 at 10:01 pm
    Jon,
    I completely agree that Deface isn't great for large-scale replacement of views that is commonly done on the front-end. Although, Alexey (a.k.a devilcoders) has amazed me with that he can achieve with them see: https://github.com/spree/spree_fancy

    The main benefit for Deface on the front end is for extensions to be able to show where their stuff should be going, but any large scale site needs to be in control of the front end completely. This does
    however make upgrades more difficult, but larger scale projects then to have more resources (and tend to stick to a version for longer periods). That said I personally love being able to add an extension into my Gemfile, restart my app and actually see the changes immediately, great for testing out extensions on a stock Spree setup.


    Anyway, that second block in application.rb is totally redundant and I've removed it from core a couple of times but it keeps coming back.

    Deface loads all overrides automatically here:

    https://github.com/spree/deface/blob/v0.9.1/lib/deface/railtie.rb#L12

    https://github.com/spree/deface/blob/v0.9.1/lib/deface/environment.rb#L23


    Note the .deface files end up in the hash anyway so there's no worries there.


    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com

    On Thursday 21 February 2013 at 21:28, Jon McCoy wrote:

    I Should also add, it appears that's the loading of *local* overrides, but given that those will be loaded after overrides that any gems may be bringing into the mix, it's having the net effect.

    I am a little concerned though, because the override import explicitly references "../app/overrides/*.rb", which means that somewhere else, some other magic is importing the .html.erb.deface files I have in the mirrored folder structure (I setup some test Defaces using this method).

    So, if I moved my line before the local overrides are imported, then provided I only used *.rb overrides, then I'll be expunging all Deface patches minus the spree/admin ones and *then* I'd be importing my local overrides. But, if I used the .html.erb.deface approach, they're already loaded and get expunged with those from gems too... :-/

    Order:

    config/boot.rb -> "~/.bundler/ruby/1.8/*/app/overrides/*.rb"
    ?? -> "../app/overrides/*/*.html.erb.deface
    config/application.rb -> "../app/overrides/*.rb"

    Hope this makes sense!

    Jon


    On Thursday, February 21, 2013 9:07:07 PM UTC, Jon McCoy wrote:
    Hi Brian,

    As nice as Deface is, I do feel that for front ends that are being restyled or modified that it can cause bigger problems than it solves. For admin interfaces and structured interfaces (ie a CRM system etc) where the style isn't being changed by end users (other than perhaps changing logos or background colours) then Deface is perfect and I wish it had been around longer than it has - I'd have had countless uses for it by now. But, for interfaces that the end user is expected to change visually (either by CSS or changing views) then I think you run risk of breaking visual flow. As you say, a big visual change is unlikely to break a spec...

    Anyway, thanks for your pointers, they've helped me solve my problem.

    Finding the right place was the difficult part as you say, I don't profess to understand Rail's inner architecture. The config hash is available in three places, depending on where you're in the stack at the time which doesn't help either (I can only wildly guess at the inheritance).

    Rails.application.config.deface.overrides
    Rails.configuration.deface.overrides
    Store::Application.config.deface.overrides

    It would seem that config/initializers/* loads too early, before require has been call for the Deface overrides. Similarly, with config/application.rb and config/environments/* it's loading too early.

    Then I spotted the config.prepare_to block in config/application.rb and where both decorators and overrides are loaded. Adding the following line after the overrides section seems to have the desired effect:

    module Store
    class Application < Rails::Application

    config.to_prepare do
    # Load application's model / class decorators
    Dir.glob(File.join(File.dirname(__FILE__), "../app/**/*_decorator*.rb")) do |c|
    Rails.configuration.cache_classes ? require(c) : load(c)
    end

    # Load application's view overrides
    Dir.glob(File.join(File.dirname(__FILE__), "../app/overrides/*.rb")) do |c|
    Rails.configuration.cache_classes ? require(c) : load(c)
    end
    Rails.configuration.deface.overrides.all.delete_if {|key,value| !key.to_s.start_with?('spree/admin') }
    end

    ...

    end
    end




    On Thursday, February 21, 2013 5:02:49 PM UTC, Brian Quinn wrote:
    Hey Jon,
    I like that term "visual testing overhead" - its been something that I've been thinking about for a while with regards to Deface. Stuff can just look different and not necessarily break in a way a spec could determine. It's a really interesting problem, and something I've got an idea on how to solve.

    So to answer your question, I think with a little Deface hack you could only allow admin overrides, here's how:

    Deface maintains a list of all the overrides loaded, accessible in Rails.application.config.deface.overrides.all , it's hash who's key is the virtual_path for the target view, see:

    1.9.3-p327 :007 > Rails.application.config.deface.overrides.all.keys
    => [:"spree/admin/users/edit", :"spree/layouts/spree_application", :"spree/admin/shared/_configuration_menu", :"spree/layouts/admin", :"spree/shared/_nav_bar", :"spree/checkout/registration"]



    You can just remove the keys that do not start with "spree/admin" and you should be good to go! Note the keys are symbols.

    I'm not 100% sure where the best place to do this is, but possibly in an initializer, you'll have to test a few options there. The problem being: will Deface have loaded all the overrides before the initializer loads ( Rails initialization process still confounds me).

    Hope that helps,

    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com

    On Thursday 21 February 2013 at 16:31, Jon McCoy wrote:

    Hi,

    I'm building a custom set of views with HAML, through various glitches I've been hit with, I decided to disable Deface. It's got it's ups and downs...

    For
    - existing overrides don't screw with my new views
    - new plugins are only implemented visually how and when I decide
    - updates to plugins don't affect my views (reduces *visual* testing overheads)

    Against
    - admin interface restricted to 'day zero'
    - have to manually rebuild the admin interface to incorporate overrides
    - updates generally bring in more changes to admin views then those for the front end, so Deface would be useful
    - would be useful to Deface my own work or the admin for temporary patches etc

    So, I suppose the big question, is whether I can specify only a specific path for Deface files? Being able to Deface my own views is purely optional and not required unless it's possible with little effort.

    How would I Restrict Deface to only files in the path structure: */app/overrides/admin

    If I change the base Deface path, then it's going to change the relative path relationship between the Deface files and the views they're patching, or can I specify both the Deface file location and the target files separately (therefore accounting for only processing Defaces located in the admin directories).

    And, which actions do I need to re-eval to override this?

    In being thorough, I'm using the views and overrides of all of the core and plugin gems as a starting point in developing my new views, so I'm not missing anything out as I work through it. It also leads to a second question, but I'll post that separately as it's related to Taxonomies.

    Regards
    Jon
    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com (mailto:spree-user+unsubscribe@googlegroups.com).
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Calvin Yu at Feb 21, 2013 at 10:13 pm
    We've recently upgraded from 1.1 to 1.3 and we actually changed our
    checkout views from erb overrides to using Deface (the rest of frontend is
    primarily erb overrides). The rationale is that the checkout flow is vital
    enough that it warrants using deface so we can better track changes in the
    Spree's checkout flow.

    On Thu, Feb 21, 2013 at 5:01 PM, Brian Quinn wrote:

    Jon,
    I completely agree that Deface isn't great for large-scale replacement of
    views that is commonly done on the front-end. Although, Alexey (a.k.a
    devilcoders) has amazed me with that he can achieve with them see:
    https://github.com/spree/spree_fancy

    The main benefit for Deface on the front end is for extensions to be able
    to show where their stuff should be going, but any large scale site needs
    to be in control of the front end completely. This does
    however make upgrades more difficult, but larger scale projects then to
    have more resources (and tend to stick to a version for longer periods).
    That said I personally love being able to add an extension into my
    Gemfile, restart my app and actually see the changes immediately, great for
    testing out extensions on a stock Spree setup.


    Anyway, that second block in application.rb is totally redundant and I've
    removed it from core a couple of times but it keeps coming back.

    Deface loads all overrides automatically here:

    https://github.com/spree/deface/blob/v0.9.1/lib/deface/railtie.rb#L12

    https://github.com/spree/deface/blob/v0.9.1/lib/deface/environment.rb#L23


    Note the .deface files end up in the hash anyway so there's no worries
    there.


    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com

    On Thursday 21 February 2013 at 21:28, Jon McCoy wrote:

    I Should also add, it appears that's the loading of *local* overrides, but
    given that those will be loaded after overrides that any gems may be
    bringing into the mix, it's having the net effect.

    I am a little concerned though, because the override import explicitly
    references "../app/overrides/*.rb", which means that somewhere else, some
    other magic is importing the .html.erb.deface files I have in the mirrored
    folder structure (I setup some test Defaces using this method).

    So, if I moved my line before the local overrides are imported, then
    provided I only used *.rb overrides, then I'll be expunging all Deface
    patches minus the spree/admin ones and *then* I'd be importing my local
    overrides. But, if I used the .html.erb.deface approach, they're already
    loaded and get expunged with those from gems too... :-/

    Order:

    config/boot.rb -> "~/.bundler/ruby/1.8/*/app/overrides/*.rb"
    ?? -> "../app/overrides/*/*.html.erb.deface
    config/application.rb -> "../app/overrides/*.rb"

    Hope this makes sense!

    Jon



    On Thursday, February 21, 2013 9:07:07 PM UTC, Jon McCoy wrote:

    Hi Brian,

    As nice as Deface is, I do feel that for front ends that are being
    restyled or modified that it can cause bigger problems than it solves. For
    admin interfaces and structured interfaces (ie a CRM system etc) where the
    style isn't being changed by end users (other than perhaps changing logos
    or background colours) then Deface is perfect and I wish it had been around
    longer than it has - I'd have had countless uses for it by now. But, for
    interfaces that the end user is expected to change visually (either by CSS
    or changing views) then I think you run risk of breaking visual flow. As
    you say, a big visual change is unlikely to break a spec...

    Anyway, thanks for your pointers, they've helped me solve my problem.

    Finding the right place was the difficult part as you say, I don't profess
    to understand Rail's inner architecture. The config hash is available in
    three places, depending on where you're in the stack at the time which
    doesn't help either (I can only wildly guess at the inheritance).

    Rails.application.config.**deface.overrides
    Rails.configuration.deface.**overrides
    Store::Application.config.**deface.overrides

    It would seem that config/initializers/* loads too early, before require
    has been call for the Deface overrides. Similarly, with
    config/application.rb and config/environments/* it's loading too early.

    Then I spotted the config.prepare_to block in config/application.rb and
    where both decorators and overrides are loaded. Adding the following line
    after the overrides section seems to have the desired effect:

    module Store
    class Application < Rails::Application

    config.to_prepare do
    # Load application's model / class decorators
    Dir.glob(File.join(File.dirnam**e(__FILE__),
    "../app/**/*_decorator*.rb")) do |c|
    Rails.configuration.cache_**classes ? require(c) : load(c)
    end

    # Load application's view overrides
    Dir.glob(File.join(File.dirnam**e(__FILE__), "../app/overrides/*.rb"
    )) do |c|
    Rails.configuration.cache_**classes ? require(c) : load(c)
    end
    Rails.configuration.deface.ove**rrides.all.delete_if {|key,value| !
    key.to_s.start_with?('spree/**admin') }
    end

    ...

    end
    end





    On Thursday, February 21, 2013 5:02:49 PM UTC, Brian Quinn wrote:

    Hey Jon,
    I like that term "visual testing overhead" - its been something that I've
    been thinking about for a while with regards to Deface. Stuff can just look
    different and not necessarily break in a way a spec could determine. It's a
    really interesting problem, and something I've got an idea on how to solve.

    So to answer your question, I think with a little Deface hack you could
    only allow admin overrides, here's how:

    Deface maintains a list of all the overrides loaded, accessible in Rails.
    ap**plication.config.deface.overri**des.all , it's hash who's key is the
    virtual_path for the target view, see:

    1.9.3-p327 :007 > Rails.application.config.**deface.overrides.all.keys
    => [:"spree/admin/users/edit", :"spree/layouts/spree_**application",
    :"spree/admin/shared/_**configuration_menu", :"spree/layouts/admin",
    :"spree/shared/_nav_bar", :"spree/checkout/registration"**]

    You can just remove the keys that do not start with "spree/admin" and you
    should be good to go! Note the keys are symbols.

    I'm not 100% sure where the best place to do this is, but possibly in an
    initializer, you'll have to test a few options there. The problem being:
    will Deface have loaded all the overrides before the initializer loads (
    Rails initialization process still confounds me).

    Hope that helps,

    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com

    On Thursday 21 February 2013 at 16:31, Jon McCoy wrote:

    Hi,

    I'm building a custom set of views with HAML, through various glitches
    I've been hit with, I decided to disable Deface. It's got it's ups and
    downs...

    For
    - existing overrides don't screw with my new views
    - new plugins are only implemented visually how and when I decide
    - updates to plugins don't affect my views (reduces *visual* testing
    overheads)

    Against
    - admin interface restricted to 'day zero'
    - have to manually rebuild the admin interface to incorporate overrides
    - updates generally bring in more changes to admin views then those for
    the front end, so Deface would be useful
    - would be useful to Deface my own work or the admin for temporary patches
    etc

    So, I suppose the big question, is whether I can specify only a specific
    path for Deface files? Being able to Deface my own views is purely optional
    and not required unless it's possible with little effort.

    How would I Restrict Deface to only files in the path structure:
    */app/overrides/admin

    If I change the base Deface path, then it's going to change the relative
    path relationship between the Deface files and the views they're patching,
    or can I specify both the Deface file location and the target files
    separately (therefore accounting for only processing Defaces located in the
    admin directories).

    And, which actions do I need to re-eval to override this?

    In being thorough, I'm using the views and overrides of all of the core
    and plugin gems as a starting point in developing my new views, so I'm not
    missing anything out as I work through it. It also leads to a second
    question, but I'll post that separately as it's related to Taxonomies.

    Regards
    Jon

    --
    You received this message because you are subscribed to the Google Groups
    "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to spree-user+...@googlegroups.**com.
    For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
    .




    --
    You received this message because you are subscribed to the Google Groups
    "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.




    --
    You received this message because you are subscribed to the Google Groups
    "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jon McCoy at Feb 21, 2013 at 10:16 pm
    I'm still working on the templates, so I might consider leaving the
    checkout process to the Spree erb and using Deface there...
    On Thursday, February 21, 2013 10:12:39 PM UTC, Calvin wrote:

    We've recently upgraded from 1.1 to 1.3 and we actually changed our
    checkout views from erb overrides to using Deface (the rest of frontend is
    primarily erb overrides). The rationale is that the checkout flow is vital
    enough that it warrants using deface so we can better track changes in the
    Spree's checkout flow.


    On Thu, Feb 21, 2013 at 5:01 PM, Brian Quinn <br...@spreecommerce.com<javascript:>
    wrote:
    Jon,
    I completely agree that Deface isn't great for large-scale replacement of
    views that is commonly done on the front-end. Although, Alexey (a.k.a
    devilcoders) has amazed me with that he can achieve with them see:
    https://github.com/spree/spree_fancy

    The main benefit for Deface on the front end is for extensions to be able
    to show where their stuff should be going, but any large scale site needs
    to be in control of the front end completely. This does
    however make upgrades more difficult, but larger scale projects then to
    have more resources (and tend to stick to a version for longer periods).
    That said I personally love being able to add an extension into my
    Gemfile, restart my app and actually see the changes immediately, great for
    testing out extensions on a stock Spree setup.


    Anyway, that second block in application.rb is totally redundant and I've
    removed it from core a couple of times but it keeps coming back.

    Deface loads all overrides automatically here:

    https://github.com/spree/deface/blob/v0.9.1/lib/deface/railtie.rb#L12

    https://github.com/spree/deface/blob/v0.9.1/lib/deface/environment.rb#L23


    Note the .deface files end up in the hash anyway so there's no worries
    there.


    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com

    On Thursday 21 February 2013 at 21:28, Jon McCoy wrote:

    I Should also add, it appears that's the loading of *local* overrides,
    but given that those will be loaded after overrides that any gems may be
    bringing into the mix, it's having the net effect.

    I am a little concerned though, because the override import explicitly
    references "../app/overrides/*.rb", which means that somewhere else, some
    other magic is importing the .html.erb.deface files I have in the mirrored
    folder structure (I setup some test Defaces using this method).

    So, if I moved my line before the local overrides are imported, then
    provided I only used *.rb overrides, then I'll be expunging all Deface
    patches minus the spree/admin ones and *then* I'd be importing my local
    overrides. But, if I used the .html.erb.deface approach, they're already
    loaded and get expunged with those from gems too... :-/

    Order:

    config/boot.rb -> "~/.bundler/ruby/1.8/*/app/overrides/*.rb"
    ?? -> "../app/overrides/*/*.html.erb.deface
    config/application.rb -> "../app/overrides/*.rb"

    Hope this makes sense!

    Jon



    On Thursday, February 21, 2013 9:07:07 PM UTC, Jon McCoy wrote:

    Hi Brian,

    As nice as Deface is, I do feel that for front ends that are being
    restyled or modified that it can cause bigger problems than it solves. For
    admin interfaces and structured interfaces (ie a CRM system etc) where the
    style isn't being changed by end users (other than perhaps changing logos
    or background colours) then Deface is perfect and I wish it had been around
    longer than it has - I'd have had countless uses for it by now. But, for
    interfaces that the end user is expected to change visually (either by CSS
    or changing views) then I think you run risk of breaking visual flow. As
    you say, a big visual change is unlikely to break a spec...

    Anyway, thanks for your pointers, they've helped me solve my problem.

    Finding the right place was the difficult part as you say, I don't
    profess to understand Rail's inner architecture. The config hash is
    available in three places, depending on where you're in the stack at the
    time which doesn't help either (I can only wildly guess at the inheritance).

    Rails.application.config.**deface.overrides
    Rails.configuration.deface.**overrides
    Store::Application.config.**deface.overrides

    It would seem that config/initializers/* loads too early, before require
    has been call for the Deface overrides. Similarly, with
    config/application.rb and config/environments/* it's loading too early.

    Then I spotted the config.prepare_to block in config/application.rb and
    where both decorators and overrides are loaded. Adding the following line
    after the overrides section seems to have the desired effect:

    module Store
    class Application < Rails::Application

    config.to_prepare do
    # Load application's model / class decorators
    Dir.glob(File.join(File.dirnam**e(__FILE__),
    "../app/**/*_decorator*.rb")) do |c|
    Rails.configuration.cache_**classes ? require(c) : load(c)
    end

    # Load application's view overrides
    Dir.glob(File.join(File.dirnam**e(__FILE__),
    "../app/overrides/*.rb")) do |c|
    Rails.configuration.cache_**classes ? require(c) : load(c)
    end
    Rails.configuration.deface.ove**rrides.all.delete_if {|key,value| !
    key.to_s.start_with?('spree/**admin') }
    end

    ...

    end
    end





    On Thursday, February 21, 2013 5:02:49 PM UTC, Brian Quinn wrote:

    Hey Jon,
    I like that term "visual testing overhead" - its been something that I've
    been thinking about for a while with regards to Deface. Stuff can just look
    different and not necessarily break in a way a spec could determine. It's a
    really interesting problem, and something I've got an idea on how to solve.

    So to answer your question, I think with a little Deface hack you could
    only allow admin overrides, here's how:

    Deface maintains a list of all the overrides loaded, accessible in Rails.
    ap**plication.config.deface.overri**des.all , it's hash who's key is the
    virtual_path for the target view, see:

    1.9.3-p327 :007 > Rails.application.config.**deface.overrides.all.keys
    => [:"spree/admin/users/edit", :"spree/layouts/spree_**application",
    :"spree/admin/shared/_**configuration_menu", :"spree/layouts/admin",
    :"spree/shared/_nav_bar", :"spree/checkout/registration"**]

    You can just remove the keys that do not start with "spree/admin" and you
    should be good to go! Note the keys are symbols.

    I'm not 100% sure where the best place to do this is, but possibly in an
    initializer, you'll have to test a few options there. The problem being:
    will Deface have loaded all the overrides before the initializer loads (
    Rails initialization process still confounds me).

    Hope that helps,

    --
    Brian Quinn

    Co-Founder, CTO
    Spree Commerce, Inc.
    http://spreecommerce.com

    On Thursday 21 February 2013 at 16:31, Jon McCoy wrote:

    Hi,

    I'm building a custom set of views with HAML, through various glitches
    I've been hit with, I decided to disable Deface. It's got it's ups and
    downs...

    For
    - existing overrides don't screw with my new views
    - new plugins are only implemented visually how and when I decide
    - updates to plugins don't affect my views (reduces *visual* testing
    overheads)

    Against
    - admin interface restricted to 'day zero'
    - have to manually rebuild the admin interface to incorporate overrides
    - updates generally bring in more changes to admin views then those for
    the front end, so Deface would be useful
    - would be useful to Deface my own work or the admin for temporary
    patches etc

    So, I suppose the big question, is whether I can specify only a specific
    path for Deface files? Being able to Deface my own views is purely optional
    and not required unless it's possible with little effort.

    How would I Restrict Deface to only files in the path structure:
    */app/overrides/admin

    If I change the base Deface path, then it's going to change the relative
    path relationship between the Deface files and the views they're patching,
    or can I specify both the Deface file location and the target files
    separately (therefore accounting for only processing Defaces located in the
    admin directories).

    And, which actions do I need to re-eval to override this?

    In being thorough, I'm using the views and overrides of all of the core
    and plugin gems as a starting point in developing my new views, so I'm not
    missing anything out as I work through it. It also leads to a second
    question, but I'll post that separately as it's related to Taxonomies.

    Regards
    Jon

    --
    You received this message because you are subscribed to the Google Groups
    "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to spree-user+...@googlegroups.**com.
    For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
    .




    --
    You received this message because you are subscribed to the Google Groups
    "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to spree-user+...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.




    --
    You received this message because you are subscribed to the Google Groups
    "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to spree-user+...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "Spree" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to spree-user+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupspree-user @
categoriesrubyonrails
postedFeb 21, '13 at 4:34p
activeFeb 21, '13 at 10:16p
posts7
users3
websitespreecommerce.com
irc#RubyOnRails

People

Translate

site design / logo © 2022 Grokbase