We have a Struts2 application using the <sx:tabbedpanel>. I know this has since been deprecated, but we have not yet had time to replace it.
We're populating the tabs by using the <sx:div> tag and specifying the href attribute, which makes an asynchronous call to the server to populate the contents of the tab. The downside to this is that we lose validation information like <s:actionerror>.
Here's what we think is happening... when the user performs an invalid action, the action class returns validation errors. When the resulting jsp is loaded, the validation messages are available. However, the <sx:div> then makes the asynchronous call back to the server to reload the contents. This time, the action class is just loading data to display, so it doesn't generate any validation messages. The results of this ajax call are then displayed in the browser, without any validation messages.
I've seen many examples on the web of using the <sx:div> tag this way within the tabbedpanel, so I'm guessing this is a problem that has been solved before, we just haven't found it.
Does anyone know of tutorials or examples that show how to do validation in this case?
Thanks for the help, I really appreciate it.
Would it make sense to put the errors outside of the tabbedpanel like:
<s:fielderror />
<sx:tabbedpanel...>
...
</sx:tabbedpanel>
Perhaps we can assist you a bit more if you can post some sample code or provide more info as to what kind of errors are expected and what the content of the tabbed panel is.
We found that we could populate the divs by using the <s:action> tag instead. This gets rendered at the time of the initial request, it does not make an ajax call later. Therefore, the JSPs have access to the validation messages and errors.
Related
To get google tag manager data we need to add code provided by google into each and every page.
I dont want to manually add the code to each and every page component in CQ,as numerous templates can be created and it becomes manual job.
Instead i want to add the HTML code into my page on every page load.
Can i achieve this using service component(java class).
If not please, provide any alternative to achieve this.
Accounting for recent posts, your requirement, if I may paraphrase, says, "I want Google Tag Manager code included in all pages automatically, except on the pages where the author doesn't want it." In that case, your option is some form of component instance on every page, where the component's dialog.xml has a simple include GTM/don't include GTM checkbox. Alternatively, you could use a page property or a CQ5 tag. In any case, the author has to check the box or not.
you should use inheritance to achive this.
usually we got a so called "abstract" or "base" template which is more or less extending the foundtion page template were every other template can get kind of global code snipplets from.
You can put this "global" code into a seperate jsp within the abstract-template too and let people overwrite/disable that functionality in some of the extending templates (in case it is not needed in 100% of them) optionally too.
use this template in a way you would normally use the foundation components in every other template you are creating as resourceSuperType and there you go :-)
As suggested by chrysler you can use inheritance for this. Alternatively if you are very sure that you will need this google tag manager code in pretty much all the pages put the code in header/footer components assuming here that you are using header/footer in all the templates.
thanks for your reply. i am aware of this form of implementation wherein you create a parent page template and then refer to it via sling:resourceSuperType in all the child templates.
But what i wanted to know is if there is any other alternative wherein i dont have to host this code on the template's component, and the user can decide which page he wants to get tracked or not, who might not have coding knowledge.
I have an index.jsp file and I want to call a method in Bean on load of this page. How should I implement this part?
Thanks
You cannot know onload in JSP. You need to make a request to jsp by writing some javascript.
onload event is in client side and you are wanting to do some server side stuff.
These are totally two things. Do you want to do something when the HTML loaded or before the JSP is invoked.
case 1: No better ways than using jQuery ready event. It tries to wait until the page is loaded. But no one can assure this.
Example code:
$.ready(function(){
/* do something. If it is an AJAX, use $.ajax(); */
});
case 2: You can either use a filter or just simply put the code on top of the JSP file.
Not sure if it is really what you want. If you want to call a method on an object on server when your page is called, you have to ways to do it :
a scriptlet at the beginning of the page, you can put the bean that you want to call is session or application scope
do not call directly the jsp but create a servlet. Do all your java treatment in the servet, load beans in request attributes if you want to use them later in the jsp and forward to the jsp.
The latter solution avoid the scriptlet and is easier to write and to test.
I'm working on a servlet to perform some logic specific to a resourceType in sling and set information to the request to be accessible via the jsp then handing off the request to the jsp similarly to the first solution provided in this answer.
Here's some example code to represent my situation:
#SlingServlet(
resourceTypes="myapp/components/mycomponent",
methods="GET",
extensions={"html"}
)
...
#Reference
private ServletResolver serlvetResolver;
protected void doGet(....) {
setPropertiesToRequest();
Servlet servlet = servletResolver.resolveServlet(resource, "....jsp");
servlet.service(slingRequest, slingResponse);
clearPropertiesFromRequest();
}
Because of this, I've noticed that I've lost sling's selector handling (I've had to roll my own simpler version to determine which jsp to render. Full featured sling selector handling is described in more detail here). I wanted to reach out to the stack overflow community and ask what else I may be missing out on by depriving the default get handler of the request. I've scanned through the source code but I think there may be more going on.
Secondly, I'd be interested in thoughts on how and where this approach may impact performance of the request resolution.
Thanks, Thomas
Processing the business logic in Java and delegating to scripts for rendering sounds like a job for the recently released Sling Models. Using that should remove the need to implement your own handling of selectors, as those won't affect the model selection, only the rendering scripts.
Not sure what you are trying to achieve here, but the main problem seems to me that your SlingServlet handles the html extension and by itself does not have selectors to filter a bit more. Thus it of course intercepts all the requests to your component. Then you have to take care of the selectors again to be able to choose the correct JSP.
The question is, why do you use a SlingServlet for it when you anyway do the rendering by JSP?
Can't you implement your logic in the JSP or better in a bean referenced in the JSP?
In our company we use our custom tag that takes care of this, but there are public frameworks available from other Adobe Partner:
https://github.com/Cognifide/Slice
http://neba.io/index.html
Im working on a project in which I have to do the following.
I have a form that has some properties like address, personal information.
I want to use the few of the properties in the previous page to show in the other page as per few validations. I can show the properties of one page into other page by using tapestry(though I'm new to it).
I want to know if we can do the validations on the Java side in the service class, and if it is possible, how.
You can pass data between pages by multiple ways, most commonly used way is to use #Persist scoped #Property
here is a complete example of it
for validation there is a method that gets called before action phase, this document describes it well
We need some input on what is a good design pattern on using AJAX in a Java application.
Consider a simple scenario:
User clicks a button which sends a request to a Java method to fetch data from DB.
Java object is returned by method and needs to be converted into a HTML table.
HTML table is shown on JSP.
What we currently do:
On a JSP page, user clicks "Show Users" button
Button using Prototype.js calls a "middleman" JSP which forwards the request to the Java method to get the data from the DB.
The method returns the Java object to the "middleman" JSP which converts the Java object into HTML (since the AJAX call from the calling JSP won't be able to handle the Java object directly).
The HTML is then returned to the Prototype call which updates the div on the calling JSP.
Our concerns are:
We would like to keep the separation of business/presentation logic and would prefer no HTML/JavaScript code inside our Java methods.
Keeping (1) in mind, is having a "middleman" JSP an OK way to do this? Or should we return the Java object as XML/XSLT to the AJAX request?
The above way we're doing has very little JavaScript and works in all browsers.
We looked at some other packages - DWR, GWT, but either there was too much dependency on JavaScript or required UI components to be present in the Java classes.
Is our way of doing things above OK? Or is there another preferable way?
Any help/thoughts would be appreciated.
Thanks,
SP
Sounds fine. You are separating view components from model components. It shouldn't matter how the call comes to the server, AJAX or not, it should be received by a controller (a servlet say) that interacts with the model, thats your Java classes that get the data from the database and forward to a JSP page for rendering the view.
There are frameworks that could simplify the boilerplate code but the design you describe sounds fine.
I'm not sure if you noticed, but there's one significant difference between your solution and what Vincent proposed. This is that the request should be initially received by a servlet (or controller, or Struts action, etc.) rather than a "middleman" JSP.
MVC dictates that JSPs should really only we used for generating the view from the model data, flow control is better handled in Java code.