It has been a while since I've touched GWT, but I was recently looking at GWT applications to see how they accomplished certain tasks. I noticed that if you go into AdWords (a GWT application), you can manipulate table information in-line. For example, if I go into my campaign and click the pencil icon next to the ad group, a little popup will appear allowing me to change the ad group's name ... except there's no identifying information anywhere in the DOM structure. No hidden fields, no id's snuck into the div elements.
What's going on here? I've been working with interactive tables, but I've always established a click handler on a class and stuck an ID in there so I can tell what I'm editing. I've always found this as unsatisfactory. Any ideas?
It uses a JavaScript variable to get a hold on the element directly when it's created. That variable can then be stored somewhere - as long as it's accessible directly or indirectly from the the global object (document), it can be retrieved later from there.
A simple pure JavaScript example would be:
document.myParagraph = document.createElement('p');
document.body.appendChild(myParagraph);
document.mySpan = document.createElement('span');
document.myParagraph.appendChild(mySpan);
...
document.mySpan.onclick = ...
Related
I'm trying to create subpanel in Account detail view where list of elements is fetched from external REST service.
I know how to define subpanel, but have no idea how to fill it with data from external network source. Was trying to use get_subpanel_data but there I can only change SQL.
Any ideas how can I do this?
When I've done this in the the past, at least with Sugar 6, I opted distinctly not to try to create a true subpanel. The data being loaded is coming from an outside source and is loaded dynamically with the page, so why present it as if it's static data coming from Sugar? Instead, I created a custom Smarty template to use as the footer on the detail page. For such an example, you can check how it works on the Calls Edit View. I think it's the footerTpl parameter in the detailviewdefs.php or editviewdefs.php. I loaded the smarty template by creating a custom detail view for my module, so custom/modules/MyModule/views/view.detail.php - extend the base Detail View class and override the display to feed Smarty new params, then your Smarty template only needs to iterate through and present the data that your view defined.
To be super-hip and abide by MVC, you could even put your custom code into your bean (if it's a custom module) or into a custom controller method, then reference that from the view.detail.php, and still feed it from there to the Smarty template.
Alternatively, you could just load JavaScript into the Smarty template and use the JavaScript to call the third-party service, parse and present it, etc.
I realize this question is a little bit old now however it comes up fairly often so why not provide an answer with a couple possible solutions. I won't get into code but more just into the design theory of how it can work. If someone needs more specific code help then that is another question.
A couple ideas...
As you mentioned you can define a custom Function which will load in Data to the SubPanel from your own SQL Query. That is one method that I just recently got to finally put to use after knowing about it for a good year and a half.
When you go this route, you are restrained to using the Columns in the SubPanel. I assume it is using the actual Metadata files to determine which Field Columns a SubPanel can use so you pretty much need your custom data in a Database table to have the same column names as the fields defined in the SubPanel Metadata.
Obviously this works great in the right situation, however not always and that leads us into the 2nd method I know of.
The other way is pretty much what #Mattew-Poer mentioned in his answer. It means abandoning the SubPanel altogether and instead generating your own HTML. This is by far my favorite and prefered way of doing it and I have been some really custom modules due to this being possible in a custom module! I will show an example below.
(Click HERE to View full size image)
In the screenshot, you can see in this example that I have something looking Similar to a SubPanel however it is not and is much for flexible and easy to customize.
Example, to the far left column in my fake subpanel is image checkboxes. When clicked on, an AJAX request is made to change the Task row Status.
After that, the checkbox image is updated to indicate the new Status state, the Modified DateTime is updated, the Status column has color background SPANS and is also updated with the correct text and background color when the left side checkbox is clicked.
Doing any of this with the standard SubPanels is a complete nightmare and would be difficult to do some of the stuff that you are open to do when you build your own version of a SubPanel.
With that said, I have built an identical clone of the above screenshot using SugarCRM default SubPanels! It was a nightmare. I could easily update the content and HTML in some of the columns. I even had the AJAX click checkbox image to update and do all the other updates I mentioned above. It wasn't too hard and worked fairly good but it had some issues.
When you do inline edit, inline create record, or subpanel paging to load different set of record. You would then lose all the custom HTML formatting that was applied. The reason is, in the SubPanel you are limited to using the After UI load logic hook. So since the "Page" is loaded already, when an AJAX request is made to add/edit the subpanel content or load a new set of items with the paging links. It only loads the SubPanel content on those events and the whole Page content does not reload. Because the logic hook only fires off 1 time after the page loads, this newly loaded subpanel data doe not receive any of your custom HTML formatting.
In my case, this means that nice looking colored background Status spans are lost, the image checkboxes are lost, and some other functionality is lost.
Now to get super technical, I could have gone another 3rd route and instead made new Custom Field Types for each SubPanel filed that I needed to apply custom HTML to. This process is super hard in my experience and in some cases it really isn't the BEST solution.
Because of the reason explained, this is why my new modules use the Custom HTML route to generate my own version of a custom subpanel or whatever Data is needed in my Module pages! So far it is working better than I imagined and has opened doors for me to build custom SugarCRM modules that I previously didn't even realize would be possible to build due to some of the issues I mentioned above. Now I bypass them altogether and open the door to do pretty much anything!
I've got some really cool stuff for SugarCRM in the works right now. If anyone has any questions feel free to ask in a new question or for me personally in a comment here.
I add sub class information to blocks , items and buttons. When i ran the form in application it shows only prompts not shows item fields
can any one suggest what is happen here
Thank you
Little bit hard to say without more information but most likely the forms compiler is not able to find your object library. Please make sure that the object library is in the forms path.
I am a Django noob and have a situation that goes beyond the basic documentation, etc.
I am updating an ordering webpage that has a form structured as follows:
several text boxes, etc to gather general info (name, date, etc)
two separate tables for selecting (via checkbox) catalogs that are generated/managed using endless_pagination. Each table can have thousands of records, hence the endless_pagination. The first column in each table is a checkbox with value = catalog.id.
a textbox where the user can manually enter catalog IDs
a submit button
I am not sure how to keep track of what a user has selected in the two paginated tables since the checked boxes are lost when choosing a different page. Also, when the user flips back and forth between the pages, the previoulsy checked catalogs will need to be re-checked(since the checked state is not maintained). I am also not sure which tool(s) to use to deal with this.
My thought is to use JavaScript (with which I have minimal experience) to update a list of catalog IDs whenever a checkbox is checked/unchecked and:
- and attach that list to the form or
- update a variable in the form or
- send as a variable separate from the form, whichever is possible/makes more sense.
I'm hoping that maintaining a list of catalog IDs is possible because the next iteration of this form will likely include some sort of filtering so I'm trying to devise a solution that will not have to be reworked later.
I have reviewed a lot of posts but I believe the closest solutions are rendered useless because of the endless_pagination.
Let me know if further clarification is required. Thanks in advance for any suggestions.
UPDATE
I tried using JavaScript to store the catalog IDs in an array when a checkbox is checked. This does not work when a user selects another page in the pagination. The array of checked catalog IDs is lost when the page 'reloads'.
I'm running into this problem right now as well. I'm handling this by writing the checked items to localStorage so they carry across to page 2, 3, etc.. as well as show up as already checked when you go back to page 1. Then every time the page loads, either find and check the existing checkbox, or create a hidden input with the appropriate name and value and append it to the main form.
var selected_items = []
function add_item_to_checkbox(item) {
localStorage.setItem('selected_items', JSON.stringify(selected_items));
checkbox.on("click", add_item_to_checkbox);
bahh... Just look at my jsfiddle it's easier to read and yeah. I don't have to type JS into a textarea on stackoverflow.
Here is my javascript minus a few things that are specific to my code. I'm sure it could be improved upon but it works really well for my application.
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.
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?