Does anyone know how I can get the same pop up via a button located on different pages (.JSF)?
That is, there is a button "add file" which then opens a pop up with a form where the user adds information about the file. As the pop up is always the same I was thinking of using declarative components. However, I do not understand how.
You can create a taskflow which will contain your page with upload form, and then reuse it on other pages as af:region. Check out this great post with an example how to do it.
I might think about three different ways to achieve this:
1) As #Pregrad said, you can create a Bounded Task Flow and expose this BTF as region (or dynamic region) in every page you need it as a popUp window (recommended if you are using transactions)
2) You can create page templates, put the af:popUp in them and apply the template for each page (recommended if you already have templates, and you need the popUp for each page on your application)
3) You can put the af:popUp component on each page you need it, and then call it programmatically. This approach may be would give you more control on the popUp behaviour but would require you to handle it manually.
The approach you should use does really depend on your needs.
Related
I am creating an application and trying to figure out best way to deal with navigation in it. User can choose different view settings (which content to show and options to filter it). Part of settings is stored in backend in user preferences model. Another part is stored in url and managed by router. But there is more settings I want to keep. The reason: I want to be able to refresh content therefore I need to keep settings somewhere, not update content on user actions and forget how I came to this state. My question is: what is the best place for such settings? Collection object? View object? My own controller?
P.S. to make it more clear, I'm working on rss reader application. And I want, for example, to show last week posts from certain feeds which are starred etc.
Save it in the URL. Thats the only place you can really rely on. If you need more then routes use query parameter like in a classic web application and use them in the view.
I was just wondering why no code-behind or helpers were made to work with layouts? I have stuff I want to display in my layouts without having to set it up in a placeholder for every single controller.
I was also wanted to know what is the best way to persist a display-once "success-message" across many pages. For example, a user fills out a form and when it is submitted correctly they are redirected to another page. I want the user to see a success message on that other page. Is there some sort of provision in Zend Framework that makes this easier?
Well for the messages you can use the Flash Messenger helper
As far as setting up the place holders you could use a base controller and set these up in the init method overriding on descendents when necessary.
Basically, what pros/cons are there to using multiple forms in the same web page vs one form with multiple submit buttons? Any difference at?
Ah? Multiple submit buttons on a single form will all submit the entire form when pressed... there's really no advantage to having multiples, unless you're overriding how the submit process works so each button only submits it's own area. In this case they'd probably not even by submit buttons, but just buttons with sum JS code to handle submission.
Multiple forms are discrete spaces of data collection, each can have it's own submit button... but only one of them can be sent at a time (and depending on the browser you may loose what's in the other forms).
Neither approach is particularly good from a user interface perspective since it'll be confusing.
The real question is, what are you trying to do that prompts you to ask this?
The two behave differently and there are good reasons to choose one over the other.
Multiple Forms on a page allow you to send data to two different locations. A common example is to have an input form as the main focus of a page going to one location, and a search form that appears as part of the generic header/footer. These both go to separate locations and submit only the HTML form elements within their appropriate <form/>
Multiple submit buttons offer you the ability to give different purpose to a submitted set of form elements. E.g. One form may have a bunch of submit buttons all with name attributes, meaning you can add conditional logic on the server side to say: "Continue", go " Back" or even "Save for later". All reference only the form elements within it's parent tag.
Two side notes are: 1) You can't nest forms. 2) JavaScript can change this default behaviour if you wanted it to. :)
Edit: with reference to a comment you made, if you wanted to do without JavaScript (a wise choice while it's not needed), you could do some careful thinking and keep POSTing the form to itself. Each time checking which form button has been clicked (top tip, give them all the same name and you can just switch case through it) and do whatever you need to do, including performing validation. E.g: When they hit "add media", you'd save the media uploaded and return a reference of it to the screen as a hidden input. The user can then continue to add things to the other boxes and when complete, hit your save button, at which point you do all the main saving work and make sure you tie the uploaded file to it as well.
You effectively keep adding stuff to their screen until they hit the save and then you perform a save method and redirect to a thank you page (or whatever logic suits your scenario). :)
All fields in a form are sent when one of their submit button is clicked. It's for you to see if you need all fields or not.
Today I was doing this thing with Spring:
Have a page with a form and a chance to choose one item related to the form.
If you push "Choose item" the app will save somehow what you typed in the form, go to another page, let you choose the thing.
When you are back to the form it's filled with what you wrote before going to the other page, plus the item chosen.
Seems easy, but you have to take into account that for some stupid reason the user could open the page where you choose the item (maybe because of a bookmark, or because he pressed the back button 10 times to play). You know what I mean. I tried many ways, mainly based on HttpSession... I don't like any of those. None of them seems elegant. I was even thinking of using a hidden form in the other page, but given that it is not unique to this "flow" (I mean you can go to the item choose page from others as well), I will have to worry about conflicts and so on.
So what would be the preferred way for you? Suggestions?
Go around the problem instead of solving it. You can use a modal javascript div popup where the user can pick the item she wants. The contents of this div can be loaded via ajax (separate Spring MVC controller called with Http GET). Once the selection has been made, you close the popup (hide the div) and copy the value into the original form. Done.
No need to store the state anywhere.
I suggest Spring Web Flow.
Spring Web Flow compliments the Spring MVC.
Here is link to Spring Web Flow Demo
In GWT, I would like to do something like a form submission that takes me to a new page, with new style sheet and new static elements, and when I get there, be able to extract the values of GWT variables still in GWT. In other words, I want to do most of the form processing on the client side instead of sending it to a servlet to be processed and sent back. Is that possible? Would FormPanel allow me to do that? How do I access the contents of the form fields in GWT on the new page?
I'm not sure I'm getting the right picture here, but I see several possibilities:
Pass the variables in the url like example.com/myform#create/param1/param2 or any other format you want, then read it using the History class
Use something like this - create an iframe from GWT (maybe put it in Lightbox or something similar), populate it the way you want using the current state of the app, and when the user is finished, he'll just close the (Lightbox) frame and get back to the main application
You could also pass around data in a "hidden" way (no visible data in the url or even through POST) using the window.name hack - there's even a sample implementation for GWT to get you started
ATM, I prefer the second option, since it goes best with the whole no refresh, same page, one app, GWT thing :) That is, unless I'm getting the wrong picture and you want to do something else.
GWT is really meant to be used for the whole application, where "pages" are replaced by application state and URL fragments, and "form submission" is replaced by AJAX calls.
If you want to validate form fields, this can easily be done with regular JS or a library like jQuery.
I'm not sure it I get you right either, but for what I'm receiving, having a new page to process the form is not the optimal design. The reason been that you might have to write different GWT app for that which mean overheads, and creating new window (or tab) will move the user's attention away from where they are. Why not using another page WITHIN gwt to process the form with tab panel or hidden panel?