I have read this in many places "You will eventually want to create your own runtime directory and keep it in your own source repository...". Can anyone tell me how to do that? What if I don't want to lose some of the OOTB components?
Currently I am just planning to have a separate webapp for custom developed components. Let's say, I want to have "ootb" mount point for the OOTB components and blank "" mount point for custom developed components. How should I do that? This is what I have tried without success:
<webapp-list>
<webapp name="webroot" http-port="8080" https-enabled="false">
<root-screen host=".*/ootb" location="component://webroot/screen/webroot.xml"/>
</webapp>
<webapp name="customroot" http-port="8080" https-enabled="false">
<root-screen host=".*" location="component://customroot/screen/customroot.xml"/>
</webapp>
</webapp-list>
If this does not work then one other solution that I can think of is to just have the "customroot" entry, and add the "webroot" as SubScreenItem in it. The "customroot" screen will just be blank, and my custom decorator will be present in the "customapps" screen which will be a counter part of the "apps" screen. And all my screens will use the "customapps" screen.
Although I haven't tried what I wrote above, but that somehow feels like a hack. I believe there should be some better way to do this.
And yes, I have read the article, I want to use localhost and there should be some way to do it with localhost too.
As explained in the other StackOverflow question you linked to (on the word "article") the webapp element used at runtime is selected based on the "moqui-name" context-param from the web.xml file for the webapp (in or out of a WAR file). Unless you are deploying multiple WAR files or other forms of webapps this is not useful.
What you are describing would be handled by adding subscreens in the screen hierarchy at the desired points. The general idea with the screen hierarchy in Moqui is that you can have root screens of "applications" mounted through various means (see the annotations on the subscreens element or the Making Apps with Moqui book for details on the 3 ways of doing this). Part of the point of this is to AVOID multiple webapps mounted in the servlet container because that makes things more complicated, including: handling authc and sessions, configuration and deployment, and so on.
Generally for an application in a component you'll want to use a database record to add a subscreen to an existing screen in the hierarchy, mainly from the "webroot" component. Here is an example of that from the example app in Moqui (this adds an "example" path elements under the "apps" path element, where the apps.xml screen is mounted under the root screen, putting it at /apps/example):
<moqui.screen.SubscreensItem screenLocation="component://webroot/screen/webroot/apps.xml"
subscreenName="example" userGroupId="ALL_USERS" menuTitle="Example" menuIndex="8" menuInclude="Y"
subscreenLocation="component://example/screen/ExampleApp.xml"/>
Here is an example from PopCommerce to mount the root screen of the application under the root screen instead of the "apps" screen (i.e. making it located at /popc instead of /apps/popc; note that this means the decoration in the apps.xml screen will not be used because it's not in the render path):
<moqui.screen.SubscreensItem screenLocation="component://webroot/screen/webroot.xml"
subscreenName="popc" userGroupId="ALL_USERS" menuTitle="POP Commerce" menuIndex="9" menuInclude="N"
subscreenLocation="component://PopCommerce/screen/PopCommerceRoot.xml"/>
I think I might have asked a confusing question, but thanks for your time David. If I try to rephrase my question, it would be: "How to have a decorator screen which will not use any HTML from the webroot or apps screens?"
I think I found the answer. I just added my customroot screen as SubScreenItem under webroot screen, and mentioned the attribute standalone="true" in it. Now my URL: localhost:8080/customroot/foo does not use anything mentioned in webroot or apps screens.
Just that, now if I want to have all my components to be at root level in URL like: localhost:8080/foo
I think the only way to do that would be to shift the OOTB components to some other URL like: localhost:8080/ootb/apps/AppList
To do that I will have to add webroot as SubScreenItem of the customroot screen, and replace the webapp entry of webroot with that of customroot.
Damn, I tried so hard and it still is confusing.
Related
This question already has answers here:
Mount react-admin under /admin
(4 answers)
Closed last year.
I am trying to integrate react-admin into an existing react app and am able to get the basic starter pages up and running , however, after adding a dummy resource and clicking on it in the UI, I am redirected to http://my-application.net/[resource name], which is incorrectly showing my applications error page.
I am trying to set up react admin in a sandbox-like scenario to avoid conflicts with some custom stuff I'm using for routing* and I currently have things set up to display react-admin under the /admin path in my app. Is it possible to tell react-admin to prefix all of its links (i.e. when clicking on a resource) with admin so that my app can correctly detect and route these pages to react-admin? For example, in the scenario from the last paragraph, when clicking on the dummy resource, i want it to direct me to http://my-application.net/admin/[resource name] instead of http://my-application.net/[resource name]
The closest I have been able to get is this SO post, which talks about adding admin/ as a prefix to the name of all resources. I have been able to make this work with some tweaks to my routing configuration to send all /admin pages to react-admin, but changing the resource names like this also has the side effect of changing them in the UI (i.e. my users resource appears as admin/users in the sidebar of react-admin)
Other things I looked at that didn't seem to be useful:
Using the customRoutes prop in <Admin>
<Resource>'s props seem to be intended more for tweaking the end of urls for different CRUD operations
this SO post seems like it might be about something different since this is the first mention ive seen of UrlField.
Does React-admin have an option to automatically add a baseUrl to all it's links?
* While not relevant for this question, the reason I am trying to do things this way is because my routing system (UniversalRouter, see here) is redux-based and appears to directly conflict with some of the redux state that react-admin needs according to the Using redux in a custom app tutorial.
An answer I found from a post the StackOverflow "related" sidebar seems to suggest that the history API has this kind of functionality:
The only other thing I can think of is properly configuring baseName in your history.
referring to this line in the OP's question (variable name changed for clarity):
const newHistory = createHistory({ basename: '/myadmin' });
Passing this modified history into react-admin's Admin component seems to achieve the intended behavior where clicking on resource links now correctly redirects to that resource underneath the specified baseURL.
<Admin ... history={newHistory} ...>
This is also mentioned in this other answer, which is way more concise than mine or the one i based this answer off of.
How do I navigate to another page within my Elm application?
Specifically, I am trying to navigate from the Home page to the Contributor page.
The Contributor page is located under my Domain folder.
The file structure is below:
- Home.elm
- Domain
- Contributor.elm
I thought I could do something like this:
a [href "Domain/Contributor.elm"] [text "click me!"]
or this:
a [href "Domain/Contributor.html"] [text "click me!"]
However, neither of these paths work.
Note:
The app that I'm working on is NOT a SPA.
You are using elm-live, which is a development server. It targets a single Elm source file as its entry point, so unless your Elm code is built as a single page application, you won't be able to do any navigation to another file (though there is nothing wrong with hard-coding href links that link elsewhere).
elm-live is also only for development. You wouldn't want to run it on a production server.
If you are trying to avoid a SPA and would rather have each Elm file represent the complete functionality for a single page, perhaps you could go with the default functionality of elm make, which generates an HTML file that contains inline javascript compiled from Elm code. This is, in essence, what drives the elm-lang.org website. If you look at the source code, you'll see the html generated by the default elm make command, compiled against each Elm file "page" of the application.
On the other hand, if you are trying to build a SPA, #Bill's answer is a good starting point.
I don't believe you can do the sort of navigation you are trying to do within an Elm app without building a SPA. You are attempting to use the HTML href attribute to navigate. That attribute needs to be a real URL. Without using something like the Elm navigation package, you wont's have support for multiple routes.
Simple navigation in Elm is fairly straightforward. I wrote a blog post on this subject.
Also, here is the github repo that demonstrates the work in this post.
In my plugin I need to track when a user views an issue using UI. Ideally I'd like to know if it was opened directly, or was viewed in Issue Navigator Detail View. I need to track who and when viewed an issue.
What's the best way to do this?
Cheers,
Oles
The most straightforward way would be to use a Servlet Filter plugin module and scan the requested URL for those corresponding to issue views. You can generally distinguish between viewing the issue directly and a view from within the Issue Navigator by examining the query parameters.
Alternatively, you could also build a Web Panel plugin module that renders no significant UI, but which would always be invoked when an issue is viewed. You'd probably want to position the web-panel on the right side of the issue view with atl.jira.view.issue.right.context.
In either scenario above, you can fetch the current user from an injected JiraAuthenticationContext.
I am currently able to popup a modal window in DNN with dnnModal.show(Url, ...);.
When I view the Url (a page within the DNN website) as a separate page, everything looks as expected (all framework and custom CSS styles apply). When I view the Url in that popup window, all the CSS is gone.
I think the fact that the Url can be anything (even outside the domain) may answer why we lose the "local" CSS. Is there a way to "retain" the website's skin on what shows up on the popup if the Url is within the site?
As an aside question, is there a proper way to load a DNN module on a popup - not the Url as above (because that is actually the Url of the DNN page that the module was put on)? If possible, that might take care of the missing CSS problem.
You might want to take a look at the way &popup=true works in DNN6/7. If you pass &popUp=true as a querystring parameter (use ? if it is the first) DNN will load the popup.ascx skin from your SKINS folder, if you don't have a popup skin defined in your skin folder, it will use the default dnn one, I believe in darkknight/popup.ascx
You can then define what popup.ascx consists of
I was wondering whether exists any dashlet which allows you to explore a site's document library. As far as I know doesn't exist such dashlet out of the box, there only exists the "Site Content" dashlet but it is slightly limited.
I have been searching around and "googling" and I found these useful resources that could be useful as a starting point if I had to create my own:
http://ecmarchitect.com/archives/2012/05/08/1592
http://code.google.com/p/fme-alfresco-extensions/wiki/GalleryPlusDashlet2
Do somebody know more dashlets/resources targeting this issue? Any suggestion?
As a temporary solution, I'm also thinking in the possibility of taking advantage of the "Web View" dashlet, by configuring in it such URL that retrieves the documentlist region/component in the documentlibrary page. For example:, share/page/components/documentlibrary/documentlist or share/page/site/{site}/documentlibrary?region=documentlist. Maybe it is crazy or what I'm saying doesn't make any sense, but it is just an idea.
Another idea that have just came to my mind is the option of creating a custom Surf/Share page which includes the component/webscript that implements the explorer of the document library, specifically the documentlist component. Then configure the "Web View" dashlet giving the URL that points to the custom page created. Would it make sense?
Thanks in advance.
You are going to see a couple of site visualization and navigation dashlets on Alfresco Visualization Tools available on https://github.com/bhagyas/alfresco-visualization-tools. The project is still at it's initial phase, but you will find interesting snippets of code used to retrieve the document library content trees within the dashlets.
The project was presented by me at Alfresco DevCon in Berlin just a week ago to bring interactive navigation and content analytics. If interested, you can find the slides at the lightening talk slides in the DevCon 2012 site at Alfresco.
Cheers! =)
Hi I've done exactly the same, it was not really needed for a Dashlet but for to embed the documentlibrary of a site in an iframe for another site.
So what I did was indeed create a new page template embedded-documentlibrary.
I've copied first the following files and renamed them:
site-data/pages/documentlibrary.xml
site-data/template-instances/documentlibrary.xml
site-webscripts/org/alfresco/documentlibrary.ftl
If you rename file 3 or put it in another folder, you need to check the paths in file 1 & 2.
So to make only the documentlibrary appear instead of everyting I just removed everything in file 3 within the <div id="alf-hd"> tag.
If you remove the tag, the document-tree will also be removed and it gave some javascript errors. This should be fixed in the latest version, but haven't tied that.
So it's extremely easy to create your own page and instead of navigating to site/documentlibrary you just navigate to site/embedded-documentlibrary or your own name you've chosen.
And yes then you'll need to use the web-view Dashlet to show it.
The only thing you need to know is, that the links open within the iframe. So if you use the web-view Dashlet, you need to open the links in a new window.
For my situation I needed an iframe, in your case you could also just let the freemarker from your Dashlet render the components needed.
There is a document-liberary-display dashlet available in the alfresco add-on list which can be used to show all the documents from document-library on site-dashlet.
http://addons.alfresco.com/addons/document-library-display-dashlet