I want to add an exception to the layout (as it is possible in www.url.de/admin/system_config/edit/section/design/ under the point themes). The thing is that I want to add this "add Exception" via code and not via the magento backend.
Is there an easy way to do that?
Based on the OP comment, the goal is to alter theme configuration for the configured default setting based on the module controller.
This seems like a Bad Idea™. Changing theme configuration behind the scenes is going to be (1) ineffective or (2) confusing to the person administering the site.
If the design assets are being matched above the configured default field, the design exception will not apply
If the design exception does apply, it silently alters standard Magento design configuration modeling
If possible, it would be better (in your controller class or superclass) to add a custom handle to the core/layout_update object instance and then leverage the layout update system to do this.
Related
Continuing to work on my port of a CakePHP 1.3 app to 3.0, and have run into another issue. I have a number of areas where functionality varies based on certain settings, and I have previously used a modular component approach. For example, Leagues can have round-robin, ladder or tournament scheduling. This impacts on the scheduling algorithm itself, such that there are different settings required to configure each type, but also dictates the way standings are rendered, ties are broken, etc. (This is just one of 10 areas where I have something similar, though not all of these suffer from the problem below.)
My solution to this in the past was to create a LeagueComponent with a base implementation, and then extend that class as LeagueRoundRobinComponent, LeagueLadderComponent and LeagueTournamentComponent. When controllers need to do anything algorithm-specific, they check the schedule_type field in the leagues table, create the appropriate component, and call functions in it. This still works just fine.
I mentioned that this also affects views. The old solution for this was to pass the league component object from the controller to the view via $this->set. The view can then query it for various functionality. This is admittedly a bit kludgy, but the obvious alternative seems to be extracting all the info the view might require and setting it all individually, which doesn't seem to me to be a lot better. If there's a better option, I'm open to it, but I'm not overly concerned about this at the moment.
The problem I've encountered is when tables need to get some of that component info. The issue at hand is when I am saving my add/edit form and need to deal with the custom settings. In order to be as flexible as possible for the future, I don't have all of these possible setting fields represented in the database, but rather serialize them into a single "custom" column. (Reading this all works quite nicely with a custom constructor and getters.) I had previously done this by loading the component from the beforeSave function in the League model, calling the function that returns the list of schedule-specific settings, extracting those values and serializing them. But with the changes to component access in 3.0, it seems I can no longer create the component in my new beforeMarshal function.
I suppose the controller could "pass" the component to the table by setting it as a property, but that feels like a major kludge, and there must be a better way. It doesn't seem like extending the table class is a good solution, because that would horribly complicate associations. I don't think that custom types are the solution, as I don't see how they'd access a component either. I'm leaning towards passing just the list of fields from the controller to the model, that's more of a "configuration" method. Speaking of configuration, I suppose it could all just go into the central Configure data store, but that's always felt to me like somewhere that you only put "small" data. I'm wondering if there's a better design pattern I could follow that would let the table continue to take care of these implementation details on its own without the controller needing to get involved; if at some point I decide to change from the serialized method to adding all of the possible columns, it would be nice to have those changes restricted to the table class.
Oh, and keep in mind that this list of custom settings is needed in both a view and the table, so whatever solution is proposed will ideally provide a way for both of them to access it, rather than requiring duplication of code.
I get the Error Unable to load DLL 'sqlite3' while I have the XAML Designer of my WP8.1 Universal project open and a Data Context set like this:
DataContext="{Binding IntakeReasonListViewModel, Source={StaticResource Locator}}"
The Locator is designed like the recommended MVVM Light View Model Locator and uses the ServiceLocator.
The error message appears only in design time and it works withouth any problems while executing. Also I have 3 apps. 2 of them have this issue, one does not. But I can't find any difference between them regarding to the SQLite.
I found different threads with the similar message, but all these problems appeard to runtime and caused some errors on saving items, while mine problem doesn't.
EDIT: I found out that the problem is that I inject my data access via a repository class to the view model. This way the designer tries to load the data access, inclusive the sqlite modul..
Does anyone know a way to avoid this for design time?
Thanks
Regards
NPadrutt
You can always use a separate ViewModel for design time. I find it a good practice to have 3 files for each View (eg. for MainPage):
IMainPageViewModel (contains bindable properties, commands etc...)
MainPageViewModel (child of ViewModelBase, implements IMainPageViewModel)
MainPageDesignViewModel (child of ViewModelBase, implements IMainPageViewModel)
This way you can avoid loading the other services, and just display some demo data that'll help you in design mode. This answer to an other question details how to use a separate service or a separate ViewModel for design time: https://stackoverflow.com/a/14154088/4788286 (With MVVMLight the key is to use the ViewModelBase.IsInDesignMode and ViewModelBase.IsInDesignModeStatic properties.)
Is it legal In MVC, so that a "model" make use of "services" to load some data ( from web) so that the data after loading can be passed into a list box of a "view" ?
My focus is on "Can Model make use of Services directly for such purposes?"
V.
I agree with Anshu's answer but I'm personally flexible about this kind of thing on my own projects if I plan them to be very small scale, that is it doesn't seem to always be worth the time to create the clear MVC separation. There's also MVVM based on MVC, some decent info on that on wikipedia and you can find it elsewhere http://en.wikipedia.org/wiki/Model_View_ViewModel
There's no set in stone rules when it comes to design pattern usage, but if you set your own rules and work within them (particularly adhering to MVC in one or more layers of abstraction) can be helpful particularly on large projects or where a team is involved.
So the answer to your question about a model making use of services is yes this is possible, is it conforming to a strict MVC pattern, no.
The model should simply be the structure that holds the data in whatever way the data relates to other data, that's what the model is made up of. The controller handles the dirty work of making the calls to the service and updating the model. The view simply is bound to or updated when changes to the model occur and makes use of the controller (usually in as3 by using event handlers on ui components) to make the right updates to the model (or calls to then update the model).
You'll likely have extra helper classes that may sort of fit somewhere in between or outside of the parts that make up the model the view or the controller, this is okay but you should be conscious of what purpose these serve and document them well and make sure it wouldn't make sense for them to somehow be handled more elegantly within the whole setup.
I would say, its rather the responsibility of the Controller to make use of services and populate the model with the data obtained from services.
This link should provide more clarity about the responsibilities of Model, View and controller in Actionscript-3
I have started a web forms project using nHibernate and objectdatasources; however, I've learned that there are some limitations that I understand but do not know to handle. These limitations include 1) objectdatasources require parameterless constructors and 2) properties of the business object cannot be read-only.
The problem I'm having is that a class in my business layer sets a property that should never change and I'd like to make sure this never happens. I'd like to set that property when the object is created, but make the property read-only so people cannot set it later. I'm not sure it's relevant to the issue, but I am using a repository class as well.
I guess I could simply make the property read/write, but I think that the business layer should enforce the rule of never changing the property. Is there a way to use objectdatasources without relaxing my business rule that a property must be read-only. If I cannot use objectdatasources, is there another best practice that does not include copying the logic of creating objects, setting their properties based on form values and then saving?
Thanks for any insight on this issue. I'm sure people have come across this in the past so I'm just looking for some direction in how to best use data sources for a web forms site. Also, any references to books or articles related to handling not so typical issues would be helpful. It seems like everything I've been looking at has you building CRUD screens...
Sean
You can map the nHibernate to fields. This may help NHibernate : map to fields or properties?
This way you should be able to have RO properties.
In all my projects till now, I use to use singleton pattern to access Application configuration throughout the application. Lately I see lot of articles taking about not to use singleton pattern , because this pattern does not promote of testability also it hides the Component dependency.
My question is what is the best way to store Application configuration, which is easily accessible throughout the application without passing the configuration object all over the application ?.
Thanks in Advance
Madhu
I think an application configuration is an excellent use of the Singleton pattern. I tend to use it myself to prevent having to reread the configuration each time I want to access it and because I like to have the configuration be strongly typed (i.e, not have to convert non-string values each time). I usually build in some backdoor methods to my Singleton to support testability -- i.e., the ability to inject an XML configuration so I can set it in my test and the ability to destroy the Singleton so that it gets recreated when needed. Typically these are private methods that I access via reflection so that they are hidden from the public interface.
EDIT We live and learn. While I think application configuration is one of the few places to use a Singleton, I don't do this any more. Typically, now, I will create an interface and a standard class implementation using static, Lazy<T> backing fields for the configuration properties. This allows me to have the "initialize once" behavior for each property with a better design for testability.
Use dependency injection to inject the single configuration object into any classes that need it. This way you can use a mock configuration for testing or whatever you want... you're not explicitly going out and getting something that needs to be initialized with configuration files. With dependency injection, you are not passing the object around either.
For that specific situation I would create one configuration object and pass it around to those who need it.
Since it is the configuration it should be used only in certain parts of the app and not necessarily should be Omnipresent.
However if you haven't had problems using them, and don't want to test it that hard, you should keep going as you did until today.
Read the discussion about why are they considered harmful. I think most of the problems come when a lot of resources are being held by the singleton.
For the app configuration I think it would be safe to keep it like it is.
The singleton pattern seems to be the way to go. Here's a Setting class that I wrote that works well for me.
If any component relies on configuration that can be changed at runtime (for example theme support for widgets), you need to provide some callback or signaling mechanism to notify about the changed config. That's why it is not enough to pass only the needed parameters to the component at creation time (like color).
You also need to provide access to the config from inside of the component (pass complete config to component), or make a component factory that stores references to the config and all its created components so it can eventually apply the changes.
The former has the big downside that it clutters the constructors or blows up the interface, though it is maybe fastest for prototyping. If you take the "Law of Demeter" into account this is a big no because it violates encapsulation.
The latter has the advantage that components keep their specific interface where components only take what they need, and as a bonus gives you a central place for refactoring (the factory). In the long run code maintenance will likely benefit from the factory pattern.
Also, even if the factory was a singleton, it would likely be used in far fewer places than a configuration singleton would have been.
Here is an example done using Castale.Core >> DictionaryAdapter and StructureMap