I'm currently migrating existing components to use the HST-2 Spring Bean Bridge to integrate better with the Spring IOC container.
I followed the Hippo documentation and everything works as advertised, at least in the running site. I can now define my component beans in my spring configuration and use DI for my component dependencies.
However, I learned that now I cannot modify the parameters on those component's in the Channel Manager's Template Composer. Before migrating those catalog components to use the SpringBridgeHstComponent I could click in the component item area in the Template Composer and get the pop up dialog which let me view and edit all the parameters to that component item
(hst:parameternames, hst:parametervalues).
Now the pop up dialog just shows a message that
"No editable properties found for this component."
I should mention that the component parameter values that were already set on the components are still available during request processing/execution. But those values are now effectively "hard-coded" because the webmaster cannot view/change them in the Template Composer.
Is this a known issue with the SpringBridgeHstComponent? Or is there a workaround configuration or something to make those component parameters available again in the Channel's Template Composer?
The Hippo CMS Channel manager can only scan annotations in the component class configured by the hst:componentclassname property.
SpringBridgeHstComponent class itself, which is used in your component
configuration now, cannot be annotated by a domain-specific parameters
info annotation. As a result, it's not shown in the channel manager
properly.
If you want to enable the parameters setting window for the
SpringBridgeHstComponent-bridged component, then you should extend the
class only for the annotation. e.g, ContactSpringBridgeHstComponent
extends SpringBridgeHstComponent with a specific annotation in that
extending class for contact component for instance. See the docs for detail.
This is needed at the moment because channel manager recognizes the
parameters information only by class annotation, which makes you extend
a new class for each component.
Related
I am currently deploying my custom controls as OSGi plugins and I wanted to do the same thing with my beans. I have tried putting them into the OSGi plugin and it works fine but the only problem I have is the faces-config.
It seems it has to be called faces-config in the OSGi plugin to work but that means i can't use beans in the NSF anymore because it seems to ignore the local faces-config.
Is there a way to change the name of the faces-config in the OSGi plugin?
Something like FEATURE-faces-config.xml?
In the class in your plugin that extends AbstractXspLibrary, you can override "getFacesConfigFiles", which should return an array of strings representing paths within the plugin to additional files of any name to load as faces-config additions. For example:
#Override
public String[] getFacesConfigFiles() {
return new String[] {
"com/example/config/beans.xml"
};
}
Then you can put the config file in that path within your Java source folder (or another folder that is included in build.properties) and it will be loaded in addition to your app's normal faces-config, beans and all.
The NSFs are running as separate, distinct Java applications. The OSGi plugin is running in the OSGi layer, above all those distinct Java applications, as a single code base. Consequently, the faces-config is only at that level.
It's possible to load them dynamically, by using an ImplicitObjectFactory, loaded from an XspContributor. That's what is done in OpenNTF Domino API for e.g. userScope (which is a bean stored in applicationScope of an NSF). See org.openntf.domino.xsp.helpers.OpenntfDominoImplicitObjectFactory, which is referenced in OpenntfDominoXspContributor, loaded via the extension point of type "com.ibm.xsp.library.Contributor".
A few caveats:
You have no control over what happens if you try to register your bean with a name the developer also uses for a different variable in that scope.
Unless you add code to check if the library is enabled, as we do, you'll be adding the bean to every database on the server.
You still need to add the library to the NSF. Unless you also provide a component that those databases will all use, there's no way you can programmatically add it, as far as I know.
It might be easier to skip the bean approach and just add an instance of the Java class in beforePageLoad, page controller class, or however you're managing the backing to the relevant XPage (if viewScope) or application (if sessionScope / applicationScope).
We're building a Spring-based application which will be delivered to end users as a distribution package. Users are responsible for properly configuring whatever needs to be configured (it's mostly about various filesystem locations, folder access permissions, etc). There's a good idea to make the app help users understand what is not configured or which parts of configuration are invalid.
Our current approach is a custom ApplicationContextInitializer which does all the environment validation "manually" and then registers few "low level" beans in the application context explicitly. If something is wrong, initializer throws, exception is caught somewhere in main(), interpreted (converted into plain English) and then displayed.
While this approach works fine, I'm wondering if there are any best practices to minimize hand-written code and use Spring whenever possible.
Here's an illustrative example. The application requires a folder for file uploads. This means:
There should be a configuration file
This file should be accessible by the app
This file should have no syntax errors
This file should explicitly define some specific property (let it be app.uploads.folder)
This property should describe the existing filesystem entity
This entity should be a folder
The app should have read/write access to this folder
Does Spring provide any tools to implement this sort of validation easily?
Spring Boot has a nice feature for context and external configuration validation. If you define a POJO class and declare it as #ConfigurationProperties then Spring will bind the Environment (external properties and System/OS typically) to its properties using a DataBinder. E.g.
#ConfigurationProperties(name="app.uploads")
public class FileUploadProperties {
private File folder;
// getters and setters ommitted
}
will bind to app.uploads.folder and ensure that it is a File. For extra validation you can do it manually in the setter, or you can implement Validator in your FileUploadProperties or you can use JSR-303 annotations on the fields. By default an external property in app.uploads.* that doesn't bind will throw an exception (e.g. a mis-spelled property name, or a conversion/format error).
If you use Spring Boot Autoconfigure #EnableAutoConfigure you don't have to do anything else, but if it's just vanilla Spring (Boot) you need to say #EnableConfigurationProperties in your #Configuration somewhere as well.
A bonus feature: if you also use the Spring Boot Actuator you will also get JMX and HTTP support (in a webapp) for inspecting the bindable and bound properties of #ConfigurationProperties beans. The HTTP endpoint is "/configprops".
In symfony2 every user created controller extends Controller Class as shown below,
class MyController extends Controller {
thus functions related to session handling are available with $this object, But controllers in Vendor and Core don't extend Controller class thus don't provide access to session related functions. So is there any way to use these functions without extending Controller class.
Presently I am using $_SESSION[], for setting and getting session variables.
Is there any way other than above.
Symfony2 provides a service for sessions, this is what you're trying to retrieve. All services in symfony2 are retrieved using the service container, which is what you're referring to with
$this->get('session');
To properly make use of the service container in your own controllers you can either...
Configure your controllers as services (see: here)
Extend the base Controller class provided by the Symfony2 stack (making the get() method available to your child Controller)
The first option is the correct way to go, you have full control over what services are then injected into your respective controllers (see service container documentation)
I am developing a web project and after much research I have decided to go ahead with JSF+Primefaces, Spring and Hibernate approach. While designing the architecture of my project I have finalized the following approach :
Actor --> JSF+PrimeFaces page --- > Backing Bean -- > Service Bean -- > Dao -- > Hibernate
Service Bean and DAO are spring beans with dependency injection.
My concern now is now with respect to backing bean:
I plan to use multiple backing beans for UI page depending upon the type of Page I need to render.
Now for example: For a new user registration page i have UserProfile.xhtml which uses UserBackingBean. UserBackingBean has UserServiceBean injected by spring. UserServiceBean has UserDao injected by Spring.
Now in UserBackingBean when the user enters the form data from UserProfile.xhtml I will have to populate the User.java domain(ORM) object.
a) What is the best practice for this ? Should I initilize the User.java in the constructor on UserBackingBean ? Is this the proper approach ? Please suggest if there is any other way out ?
b) Also please suggest on the above architecture I have decided upon for my project ? Is it the proper approach ?
The general rule I follow is that transaction boundaries are marked in the service beans therefore I don't like to modify hibernate POJO outside of a service because I don't know if there is a transaction already running. So from the backing bean I would call the service layer pass in the parameters that the service layer needs to build up the hibernate pojo and save it, update it, ... etc.
Another way to do this would be have your backing bean implement an interface defined by the service layer and then pass the backing bean to the service layer. For example.
public interface UserInfoRequest {
public String getName();
}
#Service
public class SomeSpringService {
#Transactional(.....)
public void registerNewUser(UserInfoRequest request)
{
}
}
public class SomeBackingBean implements UserInfoRequest {
private SomeService someSpringService;
public void someMethodBoundToSJF()
{
this.someSpringService.registerNewUser(this);
}
}
Regarding your last question I am not a fan of JSF, I think JSF is fundamentally flawed because it is a server component based framework. So my argument against JSF is a generic argument against server side component based frameworks.
The primary flaw with server side component based frameworks is that you don't control what the component will output which means you are stuck with the look of the component, if you want something that looks different you have to write your own component or you have to modify an existing component. Web browsers are currently evolving very quickly adding new features which can really improve the quality of an application UI but to you those features you have to write HTML, CSS, and JavaScript directly and the server side components make that harder.
Client side component architectures are here and much better than doing components on the server side. Here is my recommend stack.
Client Side Architecture:
jquery.js - Basic libary to make all browser look the same to JavaScript
backbone.js + underscore.js - High level client side component based architecture
handlebars.js - for the client side templates
Twitter bootstrap - to get a decent starter set of CSS & widgets
You write code in HTML, CSS and JavaScript organized as backbone views that talk to server side
models using AJAX. You have complete control over the client side user experience with enough
structure to really make nice reusable code.
Server Side Architecture:
Annotation Driven Spring MVC, Services and Dao (#Controller, #Service, #Repository)
Spring component scanning with autowiring by type (#Autowired, #Inject)
AspectJ Load Time Weaving or Compile Time Weaving
Hibernate
Tomcat 7
JSP as the view technology for Spring MVC (yes it cluncuky but you wont be creating
too many jsp pages, mostly for usng <% #inculde > directive
Tooling:
- Spring Tool suite
- JRebel (so that you don't have to start and stop the server) it really works really worth the money
- Tomcat 7
The real question: Is there a way to clear certain attributes for all components on an initial page load?
Background info:
In my application, I have a JSF 2.0 frontend layer that speaks to a service layer (the service layer is made up of Spring beans that get injected to the managed beans).
The service layer does its own validation, and I do the same validation in the frontend layer using my own validator classes to try and avoid code duplication somehow. These validator classes aren't JSF validators, they're just POJOs.
I'm only doing validation on an action, so in the action method, I perform validation, and only if it's valid do I call through to the service layer.
When I do my validation, I set the styleClass and title on the UIComponents using reflection (so if the UIComponent has the setStyleClass(:String) or setTitle(:String) methods, then I use them).
This works nicely, and on a validation error I see a nicely styled text box with a popup containing the error message if I hover over it. However, since the component is bound to a Session Scoped Managed Bean, it seems that these attributes stick. So if I navigate away and come back to the same page, the styleClass and title are still in the error state.
Is there a way to clear the styleClass and title attributes on each initial page load?
Thanks,
James
P.S. I'm using the action method to validate because of some issues I had before with JSF 1.2 and it's validation methods, but can't remember why... so that's why I'm using the action method to validate.
Ok, so I must use a PhaseListener, see this blog entry by BalusC and this other blog entry, that's a much better way of doing what I'm doing already - setting the styleClass manually using reflection - which gets all components with messages and highlights them... I'm gonna do the same, however think it's possible to add an attribute instead, haven't tried it yet.