I'm looking to add a new tab to specific payment methods, after the "Preferences" tab for example, to provide additional functionality to interact with the payment method. The methods are implemented using the Payment services framework.
Unfortunately the Payment cookbook in the Knowledge Base doesn't go into detail about the possible templates here.
Looking at payment/PaymentMethodTabs_52.isml.
There seems to be no extension point. You would have to override this template and add the new tab yourself. Preferably you should override this template, add an extension point and then write some extension that adds new tabs to the screen. This way your code can easily be migrated to the next version of intershop if they added an extension point later.
Related
What I want to develop....
I am currently developing a SaaS-solution (Symfony2) to build HTML-presentations or better slide shows. Users can log into an administration UI and create presentations. This presentations can be played later. A presentation consists of elements. The elements can be images, texts, videos, pdf and more.
This element types should be encapsulated from the user interface. So extern developers can develop such new modules (element types) with defined interfaces and inject it into the system.
If a new module is finished, we move it to a specific directory in the symfony2 directory and the system detect the new module. No hardcoded-changes in the administration ui system should be neccessary.
Each module has a own "product-number". So we can use a database to enable or disable modules for different users.
What functions must be implemented by a module?
In the administration ui the user has the possibility to create a presentation and add elements of different types (the modules). User sees a timeline with the elements. When he clicks on an element, the editor for this element will be shown under the timeline (Parent-Child-View). Each module has different editors. A text-module needs other configuration-possbilities than an image-module.
So, in admin UI we need functions to edit elements:
createNewElement() creates new entry in the database (module has own tables, e.g. mod_text_elements)
renderEditorView() generates HTML which will be shown in the administration ui with module-specific inputs. E.g. image-upload/crop, WYSIWYG-editor, ...
saveEditorInputs() the module needs to handle the data entered in the editor and save it to the elements entry in the database
deleteElement() to delete an element
The output for the presentation:
Later we want to play this presentation. So a loop goes through the presentation elements and asks the modules of the element what and how to show it.
renderPresentation() to render (HTML) an element for the presentation
Database
I've made a little er-diagram of a possible solution to save the information about modules and elements in a database. The yellow entities are module-specific tables.
How to realize this in Symfony2?
My frist idea is to define an interface which have to be implemented by the modules. But which class has to implement this? Controllers?
Are modules = bundles?
How to realize the View-in-View of the editor? The editor of the module (e.g. renderEditorView()) should be viewed in the user interface of the administration ui.
I'd do it by hooking in to the EventDispatcher Component.
Your 'Master' Controller would define a set of events which correspond to the standard CRUD actions you've defined above ... onCreateNewElement(), onRenderEditorView(), etc. You'll probably find a dozen more to provide hooks for as you build your application (allowing plugins to add tools to a toolbar for example).
You'd define a Service (this doesn't HAVE to be a Controller Class), which looks for new 'modules' and adds their correctly-named methods as listeners for your custom application events.
Are modules = bundles? Well, that's entirely up to you. Are you going to provide a method for users to 'install' new modules specifically for your application? Then what a module needs to look like is entirely up to you. Are you going to slip Composer into the mix and allow modules to be installed that way? Places a couple of constraints on the structure, but still pretty much up to you.
How to realise the View-in-View? Again, that comes down to exactly how you define the interface for your 'Event Plugins' and what kind of access they have to resources like TWIG and YAML config.
The question you're REALLY asking is How do I add functionality to an application without hacking existing code ... and the answer is EventDispatcher. The rest is up to you.
There is another way to expand codebase with custom "modules": Dependency Injection Tags.
It works like this:
You create core of the app, which implements basic functionality and registers compiler pass which handles code extension
Modules can be part of the core app OR moved to external bundles
Each module must be registered in DI container with tag supported by your core app, so can be handled properly (adding menu positions, new element types as in your example)
Symfony DI compiles all services and stuff so all modules are available within app instantly (so you can for example iterate over collection of prepared items without need to dynamically building it)
In my opinion EventDispatcher is better for handling real-time actions, like sending notifications when new entity is created (e.g. controller/service dispatches event, some bundle subscribes it and send notification).
When you want to extend core I would recommend DI tags. Of course you have to build all the core (interfaces and whole architecture) so modules can extend existing services' data, then you only use your services.
Whole Symfony full-stack framework is based od this tags, so there is a lot of existing code to investigate for getting the concept.
Please let me know if it's clear enough what I wrote and what's in Symfony docs. If you need some additional info, I'll try to help.
So I'm working on a project with pretty specific client requirements. The want a document that, once uploaded, is automatically given a custom content model (which I've already made) and then, immediately after upload, allow the user to select aspects to add to it. If the user cancels out of the aspect selection, the document needs to be deleted.
We have a full Maven space setup for alfresco and share development and have our standard-document.xml in alfresco/src/main/resource/alfrescco/extension/model.
The question I have is, where in my share environment do I start working on this process? Would it be best to make a custom dashlet that deals with the upload process, or is there some class or function I can rewire within the Slingshot/Spring Application Context. I couldn't find any existing plugins or share amp files that I could use as a reference. Is there anything out there that currently has something similar to this functionality?
I guess you're using Alfresco's Share client, right?
you'll have to have to tweak Share's JavaScript components:
add a custom flag to "metadataRefresh" event object that is fired in x-upload.js
tweak handling of "metadataRefresh" event in documentlist.js to call the relevant action
it's gonna be a though JavaScript implementation task.
How to edit and save back the default tridion template building blocks say for Ex(Default Finish Actions) provided by SDL?
Where can i found the soucre of default TBB's? After locating and editing the TBB's, how to save back in TCM?
Editing default templates provided by SDL is not supported. They are stored in DLL and there's no way you can customize it. Maximum you can do is to disable some of the templates from being created. Alternatively you can can create your own set of default templates.
You can use the Template Builder to assemble and (test) run Compound Templates (Page and Component Templates). You can access the Template Builder from the Tools tab in the Ribbon.
The default TBBs should not be changed.
.NET TBBs are either C# fragments with the code directly accessible, or classes that implement the ITemplate interface.
Please see the following blog post to get you started:
http://www.createandbreak.net/2011/11/template-building-blocks-via-net.html
The code for (an older version of) most of the Default Template Building Blocks can be found on the Tridion forum (http://forum.sdltridion.com).
(I don't have access anymore, but maybe somebody can edit my answer and provide the link)
As others have said though, you risk getting into support trouble if you simply modify and replace them. It might be better to:
take the code from the forum as a starting point
create your own variant, making the modifications you need
compile this into a new TBB
replace the standard TBB in the Default Finish Actions with your own variant
That way you can accomplish most things, without risking support problems. When they doubt whether you broke is, you can just swap out your own variant for the original and prove them wrong.
I have a custom form that I wrote manually without using Orbeon Form Builder. I want to save the XML file to Alfresco when the form is submitted. This can be achieved with forms created with Form Builder using the workflow-send button. My question is how to use this button with forms that were writtin manually.
That button and the Alfresco functionality are part of Form Runner and they were not meant to work independently. This is not to say that it's not possible, but you will have to look at the source code and get at least a minimal understanding of it.
The place to start for Alfresco support is alfresco-model.xml. You might be able to start by including this model with XInclude in your own form. Then, that model has at least a dependency on an instance called fr-parameters-instance which provides the form and app name. This is used to read configuration properties.
The second place to look is persistence-model.xml, which is the place which actually uses alfresco-model.xml.
I'm new to Drupal, but I want to create an add-on. The add-on requires some sort of multi-page form with advanced jQuery (I already looked at the jQuery module).
The add-on requires details of the current logged in user and will also communicate with an external database.
I've been looking at tutorials concerning Module creation etc. But they mostly cover creation of simple forms, where as what I want to create is more of a plugin.
Multi page forms are a total drag. Pro Drupal Development, has a very good section on this topic, and I highly recommend that book if you are doing any Drupal development.
Online I found the following article pretty useful too (though I ultimately went with my own system).
http://www.nicklewis.org/using-chaos-tools-form-wizard-build-multistep-forms-drupal-6
There's a decent example here:
http://thedrupalblog.com/creating-multipage-form-using-forms-api
To make the most out of this, you're going to want to get pretty friendly with the Form API:
http://drupal.org/node/204270
Sadly Drupal.org seems to be missing a Drupal 6.x explanation (though plenty exist for 5.x and 4.7 oddly enough).
Multi step forms are complex by nature, but there are some methods to make it easier. I recommend that you have a look at the multistep form tools offered by the Ctools module. This blog post by Nick Lewis explains how you can use it.
I think you should think twice before going with javascript/jQuery to create your forms. Javascript is a great way to improve the user interface, but it can be easily manipulated because it's client side technology. You shouldn't rely on javascript alone for things like input validation, temporary storage of form values and controlling the flow between different steps of the form.
I feel odd saying this, but I don't think you want to use the Drupal Forms API.
The Forms API provides a lot of security features (unique token, rebuilds form after submit to compare to ensure correct form is processed, etc.) and allows other modules to modify your forms, but I think a lot of those features will get in the way of your jEditable form. Multi-page forms are not that challenging using the Forms API, but jEditable elements will be.
Your module could simply add a menu item with a page callback function that puts together your jEditable form for you. That is about as close to the world of a 'normal PHP' script as Drupal will let you get.