I'm using a decoration for the product repository to extend the following function by adding streams (dynamic product groups).
public function search(Criteria $criteria, SalesChannelContext $salesChannelContext): EntitySearchResult
{
$criteria->addAssociation('streams');
return $this->decorated->search($criteria, $salesChannelContext);
}
This doesn't seem to work with variants, even tho they're inheriting the properties none of the dynamic product groups based on those properties seem to load. The propertyIds do load for the products so the properties have been added (is default in Shopware).
It seems I was using a decorator for the wrong repository. I extended the SalesChannelProductRepository which means the ProductRepository doesn't change. See source below:
https://stackoverflow.com/a/68232258/14184263
As long as you implement the code above within a ProductRepository decorator it works for both, as SalesChannelProductRepository inherits ProductRepository.
Edit:
There does seem to be a problem with specific rules. See source below: Getting streams from product returns zero results with some rules
Related
So I have been googling how to remove any and all usage of ViewBags in favour of something more elegant and effective. Unfortunately virtually all of the information I have come across is for prior versions of MVC, and I have yet to find something that both works and is really effective.
One of my primary objective is to be able to populate both the page and the layout at the same time, so that I can add a page title to both the <h2> as well as the <title>. I also want to be able to, if needed, to supply the first paragraph of the body content, which is drawn from the database as a separate column, to the meta-description (this is a special case where all first paragraphs are their own separate entry in the row in the db, purely for the purpose of also acting as the meta-description).
I have run across something that I believe will meet my needs, but I cannot seem to properly implement the fifth code block:
Now create the view base class. You need to create two versions to
have support for typed views.
public class ViewBaseWithLayoutModel : WebViewPage{
public LayoutViewModel LayoutModel {
get { return (LayoutViewModel)ViewBag.LayoutModel; }
}
}
public class ViewBaseWithLayoutModel<T> : WebViewPage<T>{
public LayoutViewModel LayoutModel {
get { return (LayoutViewModel)ViewBag.LayoutModel; }
}
}
Specifically, it is the “create the view base class” that has me tied up in knots -- are they talking about an entirely new section in the project, similar to the Views, Controllers, Models, Extensions, Validators, etc., such that the namespace would be namespace Project.ViewBase {?
And if I can put the fifth code block straight beside another controller like BaseController (inside the Project.Controllers namespace but below the BaseController class in that file), why do both classes throw the errors,
'ViewBaseWithLayoutModel' does not implement inherited abstract member 'WebPageExecutingBase.Execute()'
As well, the sixth code block references
<pages pageBaseType="Namespace.To.ViewBaseWithLayoutModel">
So in the above case would it be 'Project.Controllers.ViewBaseWithLayout'?
Any help would be greatly appreciated.
I have an excerpt defined on a Repo like this:
#RepositoryRestResource(excerptProjection = ListAccountProjection.class)
public interface IAccountRepository extends IRepository<Account> {
When I exec GET /accounts it works like expected.
I have another Projection ShortAccountProjection.
When I exec GET /accounts?projection=short it is simply ignored. So the projection param will never override the exerpt projection from the repo?
When I remove the excerpt from the repo, the projection "sort" works as expected.
If you define an excerpt projection, it is always applied when the collection resource is accessed (/accounts in your case), or the resources is added as _embedded within another resource.
Your ShortAccountProjection will apply only for item resources (e.g. GET /accounts/{id}?projection=short).
Eventually, take a look at Why is an excerpt projection not applied automatically for a Spring Data REST item resource?
I am making a Joomla 3.2 component by following the Lendr tutorial. They seem to add all of the database columns to their model as protected fields (use helper get/set functions to manipulate them) and CRUD operations as functions. Their table class only contains a constructor:
function __construct( &$db ) {
parent::__construct('#__lendr_books', 'book_id', $db);
}
When they are getting or saving an item, they return an instance of their table class rather than an updated version of the model e.g. if you saved a new item, the protected ID field on the model would be zero, but the ID on the returned table object would be non-zero.
So to me, it doesn't make sense to put all of the columns on the model and it would be better to explicitly declare them on the table class, or keep them updated on the model and don't return any table objects.
Components built into Joomla aren't using the new MVC convention and seem to be all over the show with where to but the CRUD operations.
Is there a clear definition of what the Model should do and what the Table should do in Joomla 3.2 using the non-legacy MVC classes?
It appears to be like this:
JTable Seems to be similar to Ruby on Rails' ActiveRecord::Base. It models the database and there is not really a need to put anything extra in here besides a constructor which declares the table name and primary key and possibly override some methods e.g. check. Basic CRUD operations are provided by JTable which will usually be called by your class that extends JModelBase.
function __construct( &$db ) {
parent::__construct('#__my_table', 'id', $db);
}
JModelBase handles the business logic of your model as well as preparing queries (which will often return the corresponding JTable values. The controller should always deal directly with this and not JTable.
In both cases there is not a need to explicitly add the database columns as properties on the class (just like in Rails).
I am looking for the solution to customize the linked admin class when I use a sonata_type_model_list form type in my admin classes.
An example :
I have 2 admin for one entity named EntityA:
class EntityA
class EntityA1Admin
class EntityA2Admin
This entity is linked in many_to_one relationships with others entities : EntityB and EntityC.
In EntityBAdmin I want to call A1Admin on $formMapper->add('entityA','sonata_type_model_list');
In EntityCAdmin I want to call A2Admin on $formMapper->add('entityA','sonata_type_model_list');
Is there any solution to set manually the admin class that should be call by sonata_type_model_list ?
At least, if it's not possible, is there anyway to customize the default filters in the list view ? (is it possible to customize $dataGridValues through sonata_type_model_list field ?)
Thanks by advance (I already spend hours to find the solution in the code, but i can't find any clear solution....)
If I were you, I would go against using multiple admins for a single entity. I would first try to use some sort of context or parameters, to distinguish on what to show and what to not show in each case for the same EntityA admin (instead of using two separate admins for EntityA).
I believe you want to change filters that are shown in sonata_type_model_list. You might want to try this to know, whether you EntityA admin is being called from within sonata_type_model_list window:
protected function configureDatagridFilters(DatagridMapper $filterMapper)
{
$request = $this->getRequest();
if ($request->query->get('pcode') == '_entity_b_code_') {
...
}
}
Then accordingly add or not add needed filter fields depending on the context.
Is there any way to get interface to play along with custom namespace? Example follows.
IHeaderRenderer.as:
public interface IHeaderRenderer{
function set header(value:IHeader):void;
function get header():IHeader;
}
HeaderRenderer.as
import fi.test.internalNamespace;
public class HeaderRenderer implements IHeaderRenderer{
internalNamespace function set header(value:IHeader):void{
// do something
}
internalNamespace function get header():IHeader{
// do something
}
}
This gives you the basic compiler error:
1044: Interface method get header in namespace fi.gridutils.headerrenderers:IHeaderRenderer not implemented by class fi.gridutils.headerrenderers.implementation:HeaderRenderer.
Why is this needed, you might ask. I'm developing a component, where the header accessors should not be directly visible to the components end user (developer), but if the developer wants to create his own Renderer he should know that they are needed. This is because the parent component will use these accessors to give the custom renderer the data it needs to render the header correctly.
Now to my mind there seems to be only three choices:
1) use public access control. This has the setback that the end developer will see accessors, which should not be directly accessed by him. Plus they add unnecessary clutter as they appear in auto-complete.
2) do not use interface. This means the end user has pretty poor options of developing the component further.
3) use the interface, but omit the accessors that use internalNamespace. Now the end developer will not know that he should add also header accessors to his custom headerrenderer class, which ends up in Flash Player giving following error to the developer in runtime:
Cannot create property internalNamespace/::header on fi.gridutils.headerrenderers.implementation.HeaderRenderer.
Sorry for all the blabbing. Any cunning ideas how this kind of situation could be handled?
In ActionScript, the interface methods need to be public. What good is an interface, if you can't guarantee the component using it can access the relevant interface methods?
that said, you can use the exclude metadata to prevent properties from showing up in code hinting.
Something like this:
[Exclude(name="header", kind="property")]
More info