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
Related
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.
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
I would like to use DocPad together with its built-in server.
For a website with a single landing page I have set up the structure as recommended on DocPad website: all page sources go into the src/documents, static files into src/files and layouts for the page sources into src/layouts. Then docpad run will generate the resulting site in the out directory and launch a web server using which I can inspect the current state in my browser.
Now, I would like to do the same with multiple landing pages. That means, I plan to deploy files to one site, http://site-one.org and other files to another site http://site-two.org. I am doing this by deploying web pages to two distinct directories /public/site-one/ and /public/site-two/ at my web hoster.
What is the most practical way to accomplish this with DocPad?
These are the things I have tried so far -- they both work (sort of), but neither is very elegant:
Let page sources go into src/documents/site-one and src/documents/site-two and static files into src/files/site-one and src/files/site-two. This renders the entire site properly and it can be uploaded easily. However, the entire DocPad infrastructure with live-reload and the built-in server no longer works (since the built-in server root directory points to out/ instead of out/site-[one|two]/ as it should).
Have two separate DocPad-installations with duplicate docpad.coffee files, duplicate plugins and partially duplicate src/* trees and then upload the resulting out tree to the corresponding sub-directory on the server.
Update: When using option 1, instead of using DocPad built-in live-reload feature it's possible to use one's own web server, point it to out/site-one on one port and out/site-two on another port and then use the grunt live-reload feature which is part of grunt-contrib-watch, where grunt is available as a plugin here. It requires adding a single line of code to the template file, see this link, and to configure the plugin, see this link.
Update 2: A possible solution would involve the ability to set a custom directory for the server. By default it is set to the out directory. While that can be changed, it is not possible to specify separate directories for the generate action and the watch action. However, I have not found such an option in the configuration files.
Turns out that this is much easier than I thought. DocPad has a scarcely documented feature called "environments". This allows to customize several of the regular configuration variables, making it easy to pick the desired landing page on the command line.
This blog post on multiple languages demonstrates exactly how to customize both the document and the output paths in different environments. Applied to my original problem it becomes:
docpadConfig = {
...
environments:
site-one:
documentsPaths: ['documents_site-one']
outPath: 'out_site-one'
site-two:
documentsPaths: ['documents_site-two']
outPath: 'out_site-two'
...
}
Then it is as simple as
docpad [generate|run|...] --env [site-one|site-two|...]
to run regular commands like generate etc. for one of the landing pages by picking the proper custom environment.
It seems to be quite basic problem, but I still cannot find a nice solution.
I made a component that uses a dialog property.
How could I avoid setting this property for every single page if this component is used also in template?
What I already have tried:
I set name attribute in dialog.xml to absolute path - Component stops working as standalone (dropped into parsys).
Move it to design_dialog.xml - First of all it's conceptually content, so I do not like such move, and again it doeas not make much sense for standalone versions.
Change resource path to absolute, while including in template:
<cq:include path="/content/site/somepage" resourceType="/apps/portal/components/myComponent" />
For the first look it was almost it. Instances included via parsys has it's own path, and Content for template is fetched from single resource... But where to store it, to make template code independent from pages tree structure?
Is there any other nice way to do so? or at least way to improve 3.?
To the original poster, the functionality you are looking for is now supported by Shared Component Properties in ACS AEM Commons (http://adobe-consulting-services.github.io/acs-aem-commons/features/shared-component-properties.html)
Compared to your suggested solutions:
No need for absolute property path required for SCP
Agreed these are "content" properties, so they should be stored as "content" instead of "design". SCP stores these values under the homepage node of a site, making them as genuine of content as any other piece of content.
Agreed that it is bad to have a template hard-coded to a content path of a single site, especially since this makes a multi-site implementation impossible without creating a bunch of templates. SCP does not have this problem, because each site has its own homepage under which the properties are stored.
If I understand correctly, you have a component which may work in two modes:
it may be included statically in the main page renderer via <cq:include>
it may be also dropped into some parsys.
In the first mode component should have some common configuration for all pages and in the second mode it should be configured separately per-instance. The problem is how to create such common configuration.
I think your 3rd solution is perfectly fine assuming that the component configuration is shared by all sites in your CQ instance. At some point it may be too strong assumption, eg. you may have a 3 language branches under /content/site-en, /content/site-fr and /content/site-de and you'd like to make a separate configuration for each branch.
I'd suggest following improvement to the 3rd solution: you may create the shared component under some relative path which will be the same for all pages, like /content/.../configuration/shared-component (where ... may be site1, site2 or site3). Then take first two parts of the current page path, add the /configuration/shared-component suffix and use <cq:include> to include path created in such way.
You may also take a different approach and create a common configuration page referenced by all statically included components. These components may try to find their configuration automatically (via the relative path as above) or they may have a single pathfield that references configuration page.
If you don't like these options (as they assume some site structure or they need some minimal configuration for each component), consider using HierarchyNodeInheritanceValueMap. It allows you to get property from the current resource and if there is no such property, it'll look into the same resource on ancestor pages. Using this you could configure your component just once, in the site root page and inherit configuration across the whole site.
I've a big GWT module which comprised of many java classes (& of course it's impossible to break it down into several modules).
My GWT application consists of some forms, but the users usually work only with a few of them, anyway they should be able to open any form as they need.
Now my problem its that gwt generates a big js file that will load each time, but most of its content may never use!
Is there any way to break the big js module file into several smaller files(for example, one file for each class) & gwt load them automatically as needed ?
You need Code Splitting - http://code.google.com/webtoolkit/doc/latest/DevGuideCodeSplitting.html
Conceptually, think of you code as a tree starting with your onModuleLoad() method. Every method call is a branch in this tree. Now GWT's code splitting is an axe that you can cut the tree at any branch. You can cut your tree anywhere and any number of times you want.
At startup, GWT will only load the part of the tree that contains onModuleLoad. Others will be loaded when you first access that part. In terms of code, other branches will be loaded ansynchronously, and you will be notified in a callback when it has finished loading.
Read the docs at the link I pasted above. It has enough material to get you started.