My custom component seems to be using the site default template index.php at the moment.
How can I get it to use a custom layout just for the component? I don't want to create an entirely new template, just a new layout file which can use the template's CSS and other assets.
Not sure if this is exactly what you are talking about - this is about the component layout. If you are talking about your entire Joomla template, this is not the answer.
Either you create a new view (but then you might need a new model, too) or you use the layout functionality. I described it here when I figured it out. In a nutshell: Go to your views/yourview/tmpl folder and create a new file newlayout.php. You'll be able to use it like this:
index.php&option=com_yourcomponent&view=yourview&layout=newlayout.
Related
A new MVC Web application has been created with Empty Razor Template. In this template I found that default controller,Model and View are missed. I need to change the template from Empty to Internet Application.
I couldn't find any option in the properties to change Internet controller. How can I do that without creating a new project?
You could create a new project in reverse. Create a new project based on the Internet template, and use a compare tool (I rely heavily on BeyondCompare) to merge the Internet template differences into your existing project.
The difference between Empty Razor Template and Internet Application Template is in two (Account and Home) Controllers, Views that go with them and in different Site.css. You can't simply "switch" between templates.
You can go from Internet Application to Empty, if you delete Account and Home Controllers and corresponding Views. Other way around is a bit more difficult. Use scaffolding to accomplish that.
You can also check differences between templates here.
usually its done by setting up the config.xml but what to do when my component needs more parameters at run-time ? There is little or zero information about, just 1-2 tutorials about custom parameters which could be used to archive the same thing but only if you're willing to write lots of bloat code for a very simple thing.
In my case my component is rather a little platform in it self, ie: users can add plugins from us. Of course I'd like to expose some options for such plugins in the component's options.
Is there any shortcut because if you look at the built-in component's code, you really don't want to do the same for each plugin...
well, thanks! any thoughts are welcome!
ps: may be there is something more compact like the Redux-Framework for Wordpress. I'd love to know there is library which can server both CMS systems.
update
'component' = Joomla component and by 'plugin' I mean my and non-Joomla plugin, hosted in a Joomla component. Imagine your Joomla component is just a host for external plugins.
You need to create a custom field type, where you'll be able to implement all the logic that's needed.
In case you need to store the values with the component, add a hidden input field, and use javascript to populate the markup on load, and insert the values you want to store on user interaction (you can also store an object encoded in json). Joomla will take care of saving and retrieving it.
the docs
I need to develop a magento extension which adds some content to particular pages such as the product view page. More specifically, on product pages, a button/link needs to be added to add the product to a third-party wishlist site.
Now I did some research, and it's not entirely clear what the best approach would be:
Use event/observers to intercept the 'core_block_abstract_to_html_after' event and adding my html there if needed
Use local.xml in app/design/frontend/base/default/layout/ to add my blocks on the correct page using either 'reference' or 'update' tags. However, can I package this local.xml in my extension? And if so, will it not possibly overwrite a user's own local.xml.
Use Magento Widgets? It looks like widgets need to be added manually to a page in the admin CMS panel, while it would be preferred to have a switch in the admin configuration to disable or enable the inclusion of the extra content.
Ideally, a user of the extension would need to do mininal configuration (or XML editing), and the extension must be compatible with existing layouts or modifications done by the user.
There's no single answer here, like anything software related it's all a question of what works best for you, your team, and your users, but here's a few general rules of thumb.
CMS Widgets are for content management. You create a widget when you want to create a simple user interface where store owners can create typed content, which can then be inserted into a page. Not a good choice to distributing an extension that needs to modify a page, or for creating an on/off feature. The ideal use case is a Magento solution provider creates specific widgets and a widget workflow, and a store owners content people update the widgets and add them to pages while managing a site's content.
The local.xml file is for layout updates that are local to this specific store/theme, and require little programatic logic. Your specific mention of adding a local.xml to app/design/frontend/base/default/layout would be a particularly poor choice for an extension you're distributing, as a user would lose this as soon as they added their own local.xml file to a theme. The ideal use case for local.xml is a developer working for a store owner (i.e. has a long term relationship with this particular Magento installation) who needs to build new pages or non-management content/interactive modules. Third party extensions shouldn't add anything to local.xml.
The official blessed way to distribute an extension that modifies an existing page would be to
Create a module
Use that module to add a new layout xml update file (see files like catalog.xml in core modules)
Use this layout update XML file to make your changes
This gives you the same functionally as local.xml, but keeps your code separate from a local user's system code. If you can add your block and implement your feature using only the features of the layout update xml files (block, reference, action, ifconfig, etc ..) this is a good choice.
Finally, there's using a core_block_abstract_to_html_after observer. This will let you add a block using pure PHP. Some PHP developers (myself included) prefer using this method as it's more programmatically transparent than using layout update xml files. The downside of using this method is if you attempt to grab a reference to a block
$block = Mage::getSingleton('core/layout')->getBlock('some_block');
$block->setSomeMethod('foo');
and some_block doesn't exist, you'll get you a fatal PHP error for calling a method on a non-object. That means your observers end up having a lot of code like this
$block = Mage::getSingleton('core/layout')->getBlock('some_block');
if($block)
{
$block->setSomeMethod('foo');
}
One of the benefits of using layout xml update files is these sorts of error silently fail on a production store (although it's that same silent failure that's maddening when developing a feature)
Hope that helps, and good luck! When in doubt, use the technique that lets your get your job done — you can always re-factor later.
I'm pretty new with TYPO3 and was wondering if you could give me an advice how to solve my problem. Basically I'm trying to make an extension that creates a custom UI for the templavoila extension. Basically my question is if you are wanting to customize the BE UI of the backend edit form, how can you possibly accomplish this? the change I wanted to make is adding another container for some options on the left side of the tabbed edit form of the generic edit page created by the class t3lib_TCEforms. Thanks!
create a extension that extends the templavoila extension with kickstarter. Add your fields under "Extend existing Tables". Use generated tca.php file and add a --DIV-- for your new tab and fields or something you want.
I've an existing MVC3 project that implements a certain functionality, this project has it's own views, and a separate Database.
now I'm required to use the same functionality inside one of my orchard project,so I thought that I can host this solution in somewhere and view it inside an iframe or something.
Am I thinking right?,
is this the correct step to take in order to achieve this requirement inside Orchard?
to make it more clear, all I need to do is to view this solution and interact with it's controls and views from a hosting page inside orchard, and the subsequent requests should be handled by my solution in order to hit it's own data store and get back with the requested data in order to be displayed to the user.
any help would be appreciated.
Update:
thanks for Bertrand Le Roy for his answer, I can now view my solution inside my
orchard website.
I came in to one more HUGE problem, which is that my application can no longer connect to my external database.
I've a DB that is hosted in some where else, and I'm using EntityFramework to deal with it.
the problem is that if I put the connection string inside my module web.config, or main orchard web.config, I run into several types of errors like:
"System.Reflection.TargetException: Object does not match target type."
or
"System.Data.MetadataException: Unable to load the specified metadata resource."
My question is: How could I pass my connectionstring correctly to my solution, assuming that I'm using Entity framework as my ORM.
Many thanks.
You will need to put it into a module.
You will have to move route definitions to a Routes.cs file (look at any existing such file for examples).
You will also need, in order to access your data store, to opt out of the ambient Orchard transaction around the data access code (using (var scope = new TransactionScope(TransactionScopeOption.Suppress))).
If you are using dependency injection, you may have some work to move that to the Autofac-based way of doing things in Orchard.
If you want your work to appear seamlessly in the Orchard admin, you may want to decorate your admin controllers with the Admin attribute. If you want your front-end to use the current theme, you'll have to add Themed attributes and maybe refactor your views so that they only emit HTML for the content zone instead of for the whole page.
Add a manifest (module.txt) to your module folder and you should be good to go.