I have
Add-on product defining a view ("my_view")
Application using this addon
Both application views.py are scanned by configurator during the application startup.
My application needs to have a more specific version of my_view, as addon provided generic my_view doesn't know about application specific details. What would be a good Pyramid pattern do this, so that Pyramid Configurator doesn't have a conflict? Can I register a view with the same name and context more specific IRequest or something along the lines?
If you want to override a view it usually "just works" if the view was defined in an addon.
config.include('cool_addon')
config.add_view(...)
This works because Pyramid will see your view is closer to the top-level of the application and just has higher priority over the view defined in cool_addon. If a structure like this cannot be achieved for some reason, the brute force approach is to config.commit() the old configuration and then add your view afterward, at which point it will overwrite the old config.
Related
We are looking to use KeystoneJS in a large project and we want to be able to customise the Admin panel. There's a nice example of how to do it here, and I've been reviewing this PR to the project. Although the example looks as if it would work for us, I don't understand the logic behind it, that is, what we would need to implement to make it work, what the possibilities and constraints are.
Is it the case that when you use the Keystone NextJS app (which is good for us), if you add a folder /admin/pages the Keystone app will look there and use those custom admin pages instead of the regular ones? I'm assuming we have full access to the rest of the app, the controllers, the DB from these pages as well....
I also noticed that JedWatson notes in https://github.com/keystonejs/keystone/pull/1019 that
Note this lacks SSR support, and I didn't put as much effort into the examples, but it's otherwise (I think) identical in functionality.
Does it lack SSR support just for the admin part, or does adding custom admin pages somehow affect SSR support in the rest of the app? (SSR is the reason we're using next)
Thanks for any info.
There are two api for custom pages, one is pages option in the admin-ui app constructor and 2nd is part of hooks api in keystone constructor.
pages: this one is legacy and only adds custom pages, it does not overwrite the existing list pages in admin-ui it only hides them if not properly configured. usually the Dashboard is visible and all lists are listed there.
hooks: this is new and expected to add more customization options, unfortunately my PRs are stale and they are not the spec keystone core team would want to add. this also does not removes any pages.
admin ui runs as react app built or loaded using webpack config. that is why there is no ssr support. even though the example use a custom admin directory but that not loaded by nextjs component, it is loaded dynamically using webpack server mounting the admin-ui react app
if you really want to have ssr, you can use some learning from closed PRs which were used as POC long ago. but that would be overkill as the admin-ui has many more updates after that.
hooks/pages have access to core limited set of access, there are some access based on React context, provider and consumer hooks. You can use react-apollo hooks as there is already provider wrapped at root of react context. you can also make use of react router hooks, they are upgraded to latest version. it has no access to server side context or controller. (not sure what you meant by controller)
Im am currently trying out different node.js templating engines, including dust.js
Is it feasible to store all layout and view content in a database instead of the file system? Is there any templating engine which would be a better fit for this case?
Ideally i would create an administration screen where i could edit all master layouts and views, without requiring any file copying.
Definitely feasible, you'll just be responsible for your own template compilation / hydration. Assuming you're using Express, the built-in view engine expects templates to be on the file system, so if you're not going to have them there you have three choices:
1) fork express to remove that check
2) pre-cache all your views in the view cache when the app starts up (so that it pulls them from the cache rather than looking at the file system)
3) ignore the view rendering Express provides and just compile your templates yourself.
Doing 3 seems like the most natural choice, but realize there's a reason Express caches compiled templates, so you may consider building your own template cache (and dealing with cache invalidation when stuff gets updated).
Actually, a 4th method which may or may not work better (untested) would be to use Express's default views rendering, but on app startup write all your view files to a virtual drive using them temp module (here)
I have been working on maximo anywhere apps recently and have a requirement to completely change the look and feel of the work execution app, the oslc layer which talks to maximo in the backend remains the same and all the functionalities are the same but there are some new buttons, notification messages and all sorts of UX aspects to be added to the app, I have just started looking at the architecture and code of the app but does anyone know how can I make changes to the front-end or is it even possible? I could find very few documents available online and all of them spoke of customizing features and functionalities but I coudlnot find any document for adding UX aspects.
It would be great someone could point out any documents or kick-off points which I can start looking into.
Thanks.
Thanks for asking, if you're just talking about adding new fields, layouts, screens to the UI, you can do that all through the app.xml, and there are lots of examples on our knowledge center, for example this one:
http://www-01.ibm.com/support/knowledgecenter/SSPJLC_7.5.2/com.ibm.si.mpl.doc_7.5.2/config_apps/t_add_rw_fields.html?lang=en
If you're talking about changing the "look" of the existing widgets, this can all be done through css, by overriding our out of the box css classes. Use Chrome inspector to figure out which css class is being used for each element type, and just override it through standard css approaches.
If you're talking about more advanced customization, for example adding your own new widget types to our screens, it is possible to programmatically instantiate/destroy your own widgets through javascript and add them to our standard application views. This code is usually hooked on the initialize and back event of our views. But you'll be responsible for writing the code to synchronize the data layer with your custom widget. We unfortunately don't have a published example of this customization usecase yet.
We always adding new widget capabilities to our Anywhere UI framework, so I'd love to hear feedback on the new widget types you're interested in.
We are trying to extend IBM Connections 4.5 CR3 with own XPages apps not on the well described widget extension level for communities but on the application level.
Our goal is to extend the applications menu and load our apps inside the connections framework just like the original blogs or forums IBM apps.
Some others tried the same thing like this one:
http://blog.riand.com/2014/06/get-your-application-integrated-within.html?m=1
It seems that the trick for coming around the CORS trouble is not well documented in there.
Mikkel has put some code onto GitHub for the server side page generation:
https://github.com/lekkimworld/ic-wrapper
Can someone over here solve this or help us to come some steps further?
There are a number of approaches you can take, depending how daring you are.
The most pragmatic approach would be:Load a connections page, steal the HTML that makes up the Menu bar, copy that into a XPages custom control and you are done (of course you had added a link to your application beforehand in LotusConnectionsConfig.xml
Check the JSP that reads the LotusConnectionsConfig.xml how it is rendering the menu bar. Configure the Apache HTTP to expose the XML for read access, so you can dynamically create that menu - saves work when your menu changes often
Use the approaches described by Phil
Add a small JS that you call in your added menu. It would remove the content of the Connections page below the menu level and insert an iFrame which loads your XPage
Cheat by building a widget for a community homepage and have just that one widget (taking the whole page as real estate) in that Community
That's just off my head. Hope it helps
Fairly new to Liferay. I learned it is possible to create plugins UI with different frameworks including JSF. Also I learned I can extend functionality of an existing plugin with hooks. Now I am curious if it is possible to add new JSF pages to an existing plugin which interface is build with JSP using hooks?
Suppose I want to extend dynamic data list portlet, add some new functionality and for this I need to add new pages.
Is it possible to add new pages in general?
Can I create a new plugin with JSF as a front end framework, implement the logic I want to add within JSF pages, would it be possible to redirect a user from an original JSP to those JSF pages, let user do something there and then return the user back to original dynamic_data_list JPSs?
If it is possible, how can I do this with Liferay 6.2?
Thanks
The mechanics are documented in the developer guide or the Wiki. It's not exactly a hook that you deploy to the running system, rather a development option to inject custom changes into existing plugins, and you deploy the modified version instead of the original one.
With this, you can do everything that you can add as extra feature this way (see the build process). Technically the answer to the first two bulletpoints is "yes". If the linked documentation doesn't help answering your third bulletpoint, please ask more specifically what actually doesn't work. But keep in mind that only core liferay is customizable with hooks, plugins are customizable at compile time - and not with hooks.