I have Liferay 7.2
I want to customize the html of the layout of the widget Documents AND Media
I tried to create a hook to document and media but it seems that is not the right way.
How can i do that?
First, the fact that you're talking about a hook tells me that you're coming from Liferay 6 or earlier. Forget the old module types ("war-style modules"), embrace the new "jar-style modules" or "OSGi modules", which leverage the OSGi methods and mechanisms in the foundation. The new module type that comes closest to the functionality of hooks would be a "module fragment".
Alternatively, if you want to create one module that overrides the JSPs of more than one other module (or overrides JSPs as a side effect to its main purpose), you may want to look into "JSP Bags".
Still, both methods are discouraged and should be taken as a last resort, according to Liferay's "Introduction to Customizing JSPs".
The preferred method would be to use Dynamic Includes (albeit they only work if the target portlet has been written to include inclusion points) or Portlet Filters (which basically allow you to programmatically edit the request to and response from the standard Portlet classes and JSPs).
Still, if you're aiming to replace most of the JSPs of the standard document and media widget (keep in mind: Widgets are still Portlets, they just have been renamed in the frontend), a module fragment still seems to the best way forward.
To identify the correct module, here are the necessary steps. I'll show it using the DLAdmin portlet from the control panel as an example:
Identify the portlet you want to edit: Look into the HTML using the DOM inspector of your browser. Look for section tags with IDs like <section class="portlet" id="portlet_com_liferay_document_library_web_portlet_DLAdminPortlet"> around the area of interest.
Now translate that ID into a package path with portlet class: com.liferay.document.library.web.portlet.DLAdminPortlet. Search for that class in the Liferay github repository. (Go there, press T, enter the class name, find its Java class source file. In case of multiple hits, you need to check the package path, too.)
Once you opened the source file, go back up in the file tree to the parent folder of the src folder. There's a bnd.bnd file. Take a look into it, it will tell you the Bundle-SymbolicName.
Use the Liferay IDE or Blade CLI (depending on your development environment) to create a module fragment for the module identified by the Bundle-SymbolicName.
Related
I am currently developing my own TYPO3 extension (in v 9.5.11) and I want to know where I have to reference the Html file that is supposed to open when you click on Admin Tools-->MyExtension in the TYPO3 sidebar.
This completely depends on how you integrated your extension; there are at least two (vanilla, Extbase) ways to make such modules. Where your template file (which is Fluid, not pure HTML) exists depends on the integration and your TypoScript configuration that defines template paths, but by default it would be in your extension, in the sub path Resources/Private/Templates/$controllerName where $controlerName is the name of the controller that renders your plugin.
Note that template paths for frontend and backend are configured separately.
If you use the vanilla way of making backend modules you most likely need to define this template manually, by setting it in the view, in which case it can be placed anywhere you like (but should of course be inside your extension).
Have a look at system extension extensionmanager, where the backend module has some registered controller classes, and methods in ext_tables.php. fx class ListController, with indexAction, unresolvedDependenciesAction, terAction, ... and more methods:
'List' => 'index,unresolvedDependencies,ter,showAllVersions,distributions',
ListController class like all other controller classes uses FLUID views, which is looking for HTML templates inside Resources/Private/Templates/<CONTROLLERNAME>/...
For ListController->indexAction it would be Resources/Private/Templates/List/Index.html where you can use TYPO3 FLUID functionality.
See also https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/BackendModules/TemplateClass/Index.html
Well, It is always recommended to write your question clearly and bit more detail so people can understand quickly.
Anyway as I understand the question, you're talking about view resource file. If you have created your extension with Extension builder, your action file will automatically be generated in the Resource folder.
BE module directory will be Resources/Private/Backend See the example here.
In the TypoScript, you will get the source path this will something look like this.
To check the backend default action, you can see the backend module configuration here. From here you will get better idea which action will be call by default (Probably List action)
In this directory, you will have all the HTML you need. Hope this will help you!
If we give cq:includeClientLib inside my component jsp and if we drag and drop the component twice on that page, will the clientlib gets loaded/included twice?
what will be the case if we do in Sightly way (data-sly-call="${clientlib.all # categories='somecategory'}") ?
And also what is the suggested method of including client libs, either create a clientlib specific to the component and load only for that component or include all the CSS and JS at a common clientlib and use it across?
No, the clientlib is only included once for a category.
This is by design as the HTL (and respective JSP tag) are evaluated during runtime and the processor keeps a map of categories that have already been included and does not include them again.
As #i.net mentioned, each category will only be included once. To answer your follow up question about the suggested method..
The best practice seems to be to define a client library for each component, which is then embedded into a "global" client library. That global client library will then be included within your page template.
/etc/designs/acme/clientlibs-all
categories=["acme-all"]
embed=[compA,compB]
/apps/acme/components/compA/clientlibs
categories=["compA"]
/apps/acme/components/compB/clientlibs
categories=["compB"]
The reason the global client library is located under /etc/designs is to prevent exposing /apps to the public. However, in AEM 6.3, you could make use of the allowProxy property to serve the code at /etc.designs/. This would then look like this:
/apps/acme/clientlibs/clientlibs-all
categories=["acme-all"]
embed=[compA,compB]
allowProxy=true
/apps/acme/components/compA/clientlibs
categories=["compA"]
/apps/acme/components/compB/clientlibs
categories=["compB"]
Adobe recently released a good tutorial of more recent best practices around client library structure: https://helpx.adobe.com/experience-manager/kt/sites/using/getting-started-wknd-tutorial-develop/part3.html
Are there any validators for Eclipse that checks that internal links between JSF web pages in the same project refers to existing pages?
I realise this is impossible to do in more complex cases, but it should be possible to do in the standard case.
One way to achieve something similar is to create Java constants for all page source files names (for example as properties in an app scoped bean) and reference them from EL, because EL validation checks those. But to do this you have to manually add all the file names which is cumbersome.
In Community 4.0.a, I'm posting my custom activities in the repo following this: http://wiki.alfresco.com/wiki/3.0_Activities_Developer_Guide
I have defined my own activity type, with custom bundles and pagelink to display custom needs in the activity dashlet.
But I face an issue, I need to specialize the output based on the activity-type in a similar way of what is done already in activity-list.get.js in the specialize() function.
I can't hack the js cause I'm packaging things in my own amp for Share.
What is the best way to do it? Is there some kind of extension point or do I need to override completely the dashlet?
The old way (3.x) to change the behaviour of a webscript controller is to copy the code and overwrite the Javascript by placing it under web-extension: alfresco/web-extension/site-webscripts/org/alfresco/components/dashlets/activity-list.get.js. There you can modify the specialize() function or whatever you need to do.
All files you place in the alfresco/web-extension/site-webscripts folder will replace original files in the share.war WEB-INF/classes/alfresco/site-webscripts classpath. Best practice is to place your customizations in the tomcat/shared/classes/alfresco/web-extension folder so you don't need to modify the WAR file.
Alfresco 4.0 provides a new way to change the javascript controllers of a webscript. You can add additional Javascript code that will run after the original code. This is preferable because you don't need to change original code and you can upgrade more easily later. To use it you need to get familiar with the new Share extension modules concept. See David Draper's Blog for more info on that.
I'm getting into Google Web Toolkit, and am a little confused about the Entry Points in GWT. Google's docs say:
If you have multiple EntryPoints (the interface that defines onModuleLoad()) within a module, they will all be called in sequence as soon as that module (and the outer document) is ready.
If you are loading multiple GWT modules within the same page, each module's EntryPoint will be called as soon as both that module and the outer document is ready. Two modules' EntryPoints are not guaranteed to fire at the same time, or in the same order in which their selection scripts were specified in the host page.
So does each page in your website need an Entry Point defined for it?
Do you only really NEED an entry point when you have javascript generated based on your Java classes?
Are you able to combine multiple auto-generated-js definitions into a single *.gwt.xml file?
EDIT: Link to quoted source: http://code.google.com/webtoolkit/doc/1.6/DevGuideOrganizingProjects.html
Thanks!
The most straightforward way to make a GWT app is to have a single page for the entire application, and a single top-level module (defined in a .gwt.xml file). Each module has a single EntryPoint class. Then all of your different "pages" are sub-sections of the same page, ideally using GWT's history mechanism to keep track of state changes that in a non-AJAX web app would be new pages. So if you set things up this way you'll need one EntryPoint for your whole app.
The bit of the docs that you quoted (link?) discuss what I think is an advanced use case, where you've got more than one module that you're loading on a single page.
there is one options, U can create maven project with sub projects, means U can create multi entrypoint,
each entry point have own html. See more details