In the feature list, oracle have mentioned the user can choose the preferred language either Java or JavaScript for writing business logic.
If it's true, how can i choose.
MAF supports content being presented in three forms: AMX components, Custom HTML + JavaScript and External Web pages. AMX is the preferred mechanism. But, you can create custom HTML/JS pages as well.
See here.
When you create the content for a Feature in MAF, you select the type of content that you want. Note: Taskflow Navigation is available only for AMX pages. With Custom HTML./JS you have to handle all navigation between pages yourself.
If you choose AMX pages you can easily navigate between pages using task flows and call Java code when events occur like button clicks, etc. it is strongly recommended to use AMX and Java for MAF. One uses JS only if their requirements cannot be met with AMX and Java which is not typical.
Related
In Kentico 11, in a custom module you are developing, when using a custom Page Template (portal mode) for the UI Element, where is the appropriate place to host Transformations used by web parts of that template? "Appropriate" meaning the transformations can be bundled with the module for import/export operations or at least grouped with it logically in Kentico admin?
The Kentico Custom Module app doesn't contain a Transformations tab for its Classes.
Repeater web parts used on the UI page template only list Custom Tables and Page Types when looking for transformations. Transformation doesn't seem to be supported for a Custom Class.
I could create a standalone container Page Type to host all transformations for the module, however this would be outside the module. These transformations would use data from Classes in the module (through repeater web parts and query data sources for example). It seems odd to put them outside so I am suspicious of doing this.
Up until now I've only used the out-of-box tab and listing web parts to create custom modules. Now I need to get into more customization, and prefer the portal mode to easily build templates using web parts. Transformations seem to be the missing consideration in this development flow.
Neither can I find Transformations mentioned in the Custom Module documentation. Kentico Documentation I'm referencing is:
Creating custom modules
Manually creating the interface for custom modules
Martin Hejtmanek's Module development articles like this one
I can find a place to put my transformations. I'm looking for thoughts about where to best put them and bundle them with my custom module work.
Your findings are a shortcoming in the module documentation. The documentation talks in great detail on how to build the module and display it within the Kentico UI but talks little to none on how to display that content outside of Kentico on the public facing website.
What you mentioned, using a custom Page Type as a container is a simple easy approach and I believe you can bundle this with your module. Yes it doesn't make sense but using this approach will allow you to have your custom queries to access the module data and display options (transformations).
You have another option to create custom webparts for this and package them with your module but I'd recommend against this because it takes away from the basic usage of Kentico and will require code maintenance and modifications for simple changes.
If you look at page types you will see that Kentico does the custom page types to hold transformations. They have ones like RSS Transformations, E-Commerce Transformations, etc.
That is the way I have always done it also.
I suggest you to take a look at the custom table module as example, i.e. user interface part of it: there is transformation menu item under edit custom table in the interface. Take a look on how it is done and try to clone/modify it for your own custom module. If you check the DB: cms_transformation table has TransformationClassID field. So transformation is attachable to a class - so you custom classes can have transformations attached. Honestly i've never done it, but this is the way how I would approach. I would keep apples with apples, oranges with oranges... yeah sure you can always create "container page type" and it will work, but i would play around with the custom module. You might need to create and extender in this case.
#John,
As per Brenden post, you can achieve this using custom web part with your custom logic.
Refer below URL:
https://docs.kentico.com/k10/developing-websites/defining-website-content-structure
I have a requirement in liferay portal to allow user to add some specific portlets on a particular page. Same can be done in 2 ways:
This will require some custom code to be plugged in add panel code
create a custom portlet which will be present on left hand
side of page and allows portlet to be added and dragged on page.
On add of portlet it checks if the page can have this portlet and accordingly remove it
The question I have is which of these 2 approaches shall be used, and how?
Note: I was unable to find much about this on google as well
I believe Liferay permission system is strong enough to express what you need.
The portlet list shown in "Add more portlets" menu can be customized through a Regular Role. See How to customize which portlets to show in “Add more portlets” menu for detailed info.
To restrict the options for a single page (or several pages), modify its permissions, so that only the new Regular Role is be able to update it.
Based on your comment to Tomáš Piňos's answer, my suggestion would be to create a custom portlet that uses Liferay's API and enables you to do just this: On the page where it's available, use it to enable/disable the portlets you'd like to be there by use of Liferay's API. You'll find quite a lot of sample when you're looking for the old sevencogs example (that sadly does not compile any more, but in general the API has only changed marginally). The most up to date resources with further links to the ancient code are these 2 blog articles.
About your third option (as you ask in the comments): Yes, it's possible: You can override Liferay's Services as well as react to model changes. This means that you could add your own check on updates. However, I'd feel it inappropriate to offer the option to add any portlet only to prohibit it whenever a user indeed uses the offered option. That's why I didn't include this option in my initial answer.
I need to use a custom control which is a simple navigation bar from another database
navigation bar is made with twitter bootstrap css framework,
why do I need to use a custom control from another database?
because this navigation bar is going to be common to four notes Databases,
how can I implement this more efficiently?, a control that is common to four databases
Domino includes template inheritance features that allow either an entire application or a specific design element (like a Custom Control) to be updated whenever the template design changes. You could link the shared Custom Control in each of your four applications to a common template so that, if you need to make changes to it, you only have to change it in one place. You can not reference a Custom Control that only exists in another application; you'd have to store it in each and link the design to keep it synchronized.
Alternatively, you can use the Extensibility API to convert it to a library component. Controls of this kind can be used in any application running on a server that has the library installed. A video tutorial for this process can be found here.
I find that Liferay concepts are quite confusing.
When I add new items, I don't know what is the best to choose:
Use the web content concept with template and structure
Use the dynamic list records
Use a specific model (using service builder).
All of these are really similars and can achieve same goals.
Have you got any clue or advice on what concept to choose when you develop some new features in Liferay?
You should use the components in this way :
Web Content : Web contents provide convenient way to create, update, view, modify, create RSS feeds, customize the content of the web site. It is one of the main component of the Liferay CMS. You should use web content when,
You have static content and want to show to the site.
You have specific structure of the content (like content with an inline image and a document link), then please use web content with the structure and template
You want to use ready to use content portlets ( web content list, web content display, web content search) instead of creating new set of portlets for your own type.
After all this, Liferay provides customization of web contents by allowing user to add new content type, creating rss feeds, structures, templates, ready workflow, content type roles etc.
Dynamic List : Consider dynamic list as a database with display functionality. Here, you can create a custom type of data and provide display functionality. If you have any requirement like user can create his/her own type of list maintain them, then go for it.
Custom Portlet : If your requirement is very case/scenario specific that you cannot achieve using list or web content or any other Liferay portlets (blogs, wiki, knowledge based articles etc) then go for custom portlet, here please remember, that at every liferay upgrade, you need to review the portlet and update the code accordingly in case of any API change or something. For OOB portlets, Liferay takes care of it.
Hope this helps!
It deends on what you want to have and how much control you want to have over your code.
To make simplistic application use web content concept with template
and structure.(need not to know technologies)
-To make some complex applications use dynamic list records
To make extremely complex applications and have full control over the flow use liferay service builder.(need t be a expert java programmer)
Hope that helps :)
I have a rather large project developed on Sharepoint and Project Server, designed as a multi-tier application. I programmatically manage web parts on certain web part pages. According to the choices of the user in one of the web pages, appropriate web parts are added to the web part collection of another web part page. My problem is that I simply do no know where to manage the web parts, should I do it in the BLL and then have the assembly containing the business logic reference the UI assembly where the web parts are? (I need to instantiate the web parts when adding them to the collection, since I do not want to use hard coded strings representing the web part dwp.)
It really depends on what pattern you're using for your BLL and UI layers, and how strictly you want to follow it.
If you're doing a MVP pattern then I'd suggest that you have the Page implementing an interface which has one (or more) of the following options:
A stack which the Presenters to load are added to
A Load_WebPartName event for each web part which then should be called to indicate which webpart(s) need loading
To be strictly MVP you should not reference the following assemblies in your BLL project:
System.Web
Microsoft.SharePoint
Microsoft.SharePoint.*
(All SharePoint assemblies would be in either the Model or UI projects, the BLL is just connecting to the appropriate hocks)
Can you package the web parts as a feature or set of features and then simply manage the feature(s) activation/deactivation through the web part manager class?
Any programmatic massaging of the web part that needs to happen on the appropriate web part page can be handled in the feature receiver, so your manager doesn't need to be so aware of the web part UI.
HTH,
jt
Web parts are generally best managed using the feature/solution framework. You may treat the webpart classes you write as any other web control, and thus a part of the ui layer. I generally keep the information in the xml files (the .webpart or .aspx files) to a minimum. If you are managing them exclusively, you don't really need to use declarative code files at all.
The short answer: webparts are sharepoint specific ui, and should have no knowledge of the business layer.
The short answer is probably "no, you should not do this in the BLL." A purist might argue that while the BLL may rightfully determine what a user can or can't do, it is up to the UI tier to determine the appropriate web parts to be displayed as a result.
For example, the BLL might determine a user's capabilities and expose them as roles, or permissions or something else with domain-related meaning (e.g. timesheet approver role, approve timesheet permission, etc.). These might then be mapped to a set of web parts by the UI tier (e.g. timesheet approval web part). In this way, the BLL effectively determines the users capabilities and the UI tier determines the UI for those capabilities.