I am working on magento custom module [created by module creator].
There is a requirement to create a Child table which maintains the relation to the default/parent table by means of primary/foreign key references.
There is a one-to-many relation from parent-to-child table.
I need to have the Grid interface and Edit interface to update/save all relevant data.
Please, provide me the way to manage this module.
I have just tried the join clause on default data collection as below:
===============================
In protected function _prepareCollection() At "\app\code\local\Klimaire\WarrantyRegProd\Block\Adminhtml\WarrantyRegProd\"
$collection->getSelect()->joinLeft('warrantyregprod_child','main_table.warrantyregprod_id = warrantyregprod_child.warrantyregprodID', 'warrantyregprod_child.prodcode');
===============================
What you are asking for is a very advanced aspect of Magento (custom Admin code and functionality). I would suggest you go through online or in-person training as this is far to complex to describe in a stackoverflow answer (I went through training, and this is honestly a 10-step process that takes about an hour just to copy/paste demo code -- custom work will probably be anywhere from 4-6 hours to complete). Your question is also somewhat incomplete -- need more info if you are having sql-specific problems. You also never want to call select statements from a Block - these should be managed by Models, and you should also call your collections from your Models.
Related
I'm new to PowerApps. I'm creating a model-driven app. I've created some custom tables in the DataVerse - Information System, and Business Process. These tables have a M:M relationship. An Information System supports one or more Business Processes and a Business Process can use one or more Information Systems. I need to capture additional attributes that describe the nature of the relationship - what role does the Information System play with respect to the Business Process, and a score indicating how effective the Information System for that Business Process.
I've learned how to create M:M relationships using the built-in functionality in PowerApps but this does not permit me to define additional attributes for the relationship.
I've created my own M:M "middle" table and created M:1 joins from that table to each of the related tables. My "middle" table contains a lookup to each of the other tables and the additional attributes I need.
I need to know how to modify the default form for each of the related tables to include the "middle" table to enable a user to select a row from the "other" table and also to supply values for the additional attributes. I have searched for several days now and have not found any literature explaining how to do this.
I'm hoping there's someone who knows how to do this or can direct me to some literature about how to do it.
Thanks in advance for any assistance you can provide.
What you did is right, initially you created a native N:N relationship and for your need it should be manual N:N relationship which you created later.
You can add the subgrid of manual N:N intersect entity (two lookups and extra attributes) in both the main entities - this way you can create related records from either side. It can be a related navigation in the form instead of subgrid as well.
Read more
Being new to app design and coding I have the following question related to Class design. I have a class by the name of Art Object which has the following other attributes:
'Type' such as 'Painting', 'Sculpture', 'Drawing', 'Collage' etc.
Categories such as 'Modern (Art Nouveau)', 'Art Deco', 'Gothic' etc.
Now my question is, how do I design this. In my opinion I have two options:
Create a separate model , say ArtObjectTypes and have all the CRUD operations. And then establish relation between ArtObject and ArtObjectType.
Create a separate model , say CustomFields on which I can have all CRUD operations. The benefit in this case is that in future I will be able to generate more custom types attach with the ArtObject or any other Object.
Please advise which of the above options I should go for and why. Also, please do bring up if there is another choice.
First ask yourself how you would organize this in your database.
Draw a schema like this:
Define the relations, the foreign keys, and only then you should start implementing the models. A model in laravel corresponds to a table in your database.
currently i am developing a Magento extension, that needs to add several custom attributes to customer address.
I've found several tutorials on the topic that describe precisely what i need to build
http://www.unexpectedit.com/magento/add-new-customer-attribute-onepage-magento-checkout
http://www.excellencemagentoblog.com/magento-adding-custom-field-to-customer-address
They all use ALTER TABLE to add columns to several db tables.My question is :
Is it upgrade safe to do this?
Thanks in advance
They're using the magento framework method addAttribute() not pure SQL queries. They're using it in an upgrade script and it's its purpose : to upgrade safely a database..
Note that the EAV mechanims of the customer entity is built in order to not alter the table definition but add data in it. So in the background customer::addAttribute doesn't do a single ALTER TABLE. On the contrary, the now flated-tables sales_flat_order/quote addAttribute method does alter the tables cause it's no more an EAV entity.
They're doing it right.
I don't really understand your question.
I often get to the point in building a new Magento site where 301 rewrites need creating for all the items on the old site. Is there a way of importing them directly?
Programmatically via a urlCreate() type Magento function would be fine as then I could just cycle through a csv.
Generally it's a good idea to stick with Magento's ORM for interacting with entity data, as there may be both business logic and storage logic which is baked into the entity ORM stack (this is notoriously true for EAV entities). But, depending on the number of records to be entered, a direct-to-db approach should be fine, especially if it's a one-off import. This is because URL rewrites are flat entities stored in the core_url_rewrite table (link), and the table itself has the necessary storage logic as part of its structure (mainly, unique request_path + store_id and an FK for core_store table). In other words, manipulating this data outside of the ORM tier is okay because the logic is part of the table definition itself.
Beyond this information, it's possible to load up a core/url_rewrite collection, create core/url_rewrite instances from the CSV and add them, and then call save() on the collection, but note that each item is saved individually. It might do to refer to the convert adapters for catalog entities and for customers, which is how dataflow works.
After building some frontend stuff, I'm now exploring the internals of the admin side of Magento. I read Alan Storm's article on creating a simple model (as opposed to an EAV model, something which I am not yet ready for).
My main goal is to create a module that enables the user to upload and manage media to the Magento installation, so that it can be used in some templates I defined in the frontend. So I would create a model to keep track of the relations between certain media (pictures) and certain categories, pages, you name it. Just for the record: I don't like EAV models, they scare me, so unless it's absolutely necessary, don't push the conversation that way. Thank you :)
I've also skimmed through this article.
It's about backend models, and my question is about that:
What IS a backend model?
Is it a model that's used only in the backend (admin)? I wouldn't know what that would be good for. If someone could tell me something about it, or give me a hint on what to read to know more about it, it'd be great.
The reason I'm telling what goal I want to reach is so that someone can tell me if these "backend models" are significant to what I want.
Thanks!
Don't worry about EAV, don't worry about "backend models". You'll need some in the trenches programming experience before you can fully understand their significance. You can get a lot done with the plain-jane Magento model classes and SQL queries.
The light version: Backend models have nothing to do with the frontend-cart/backend-admin application split. A "backend model" handles loading, storing, and persisting information into a datastore (the database). A "frontend model" is PHP code that handles rendering a user interface element to display the attribute in the web browser. The terms are used in several different systems in Magento, including EAV and the System Configuration section.
The article you linked to is talking abou EAV backend models. Again, the light version: Each data property of an EAV model is, itself, an object. For example, in a simpler system you'd store the product's name as the string 'Bicycle'. In Magento you assign a product attribute object to the parent EAV model for name. This way, the code for saving "name" to the database can be kept separate from the other saving code.
Long story short, It's overkill for what you're after.
In Magento backend attribute models is used to prepare data before placing it in the database. This preparation is done by beforeSave method. A good exampe is Mage_Eav_Model_Entity_Attribute_Backend_Datetime