Is there any header composite availabe in swt? What my requirement is I should have one user login form available in SWT. That form should be able to show inside the view. And that form should have one caption also. First I thought to use some kind of dialogs. But I dont want to
use any dialogs. Is there any way which I can implement the same?
There is an API called Eclipse Forms which was only introduced in Eclipse 3.3, so many books don't mention it. It lets you organize forms in a somewhat web-like way, with headers and sections and boxed groups and such. I think this would probably meet your needs.
Try to look at LoginDialog in Opal SWT Widget Library. It provide a ready-to-use and configurable login dialog. Maybe it will be suitable for you.
Related
I am working with Vaadin for a long period of time, but one thing really annoys me: The colorless ComboBox. As I found out, it is not possible to set the items via HTML or to add a color style attribute via ItemStyleGenerators. The last option to do this is implementing extensions as mentioned here: Question-link
But I have really no idea how to do this. Implementing extensions is really not as clear as possible and there are not that many easy tutorials on how to do this.
Has anyone an idea for how to do this or a good link to any detailed tutorial site?
To realize what extensions are, you must to read about client side Vaadin development. I suggest to start with: Client-Side Development
After that you can start to think about extensions.
My question: What is the advantage of using the Eclipse ConsoleManager class in opposite of putting my console in a view.
I have created my own console (a REPL) in java and would like to integrate it with Eclipse. I know of two ways to do so:
Create a plug-in view and just display my own textpane in it. Example code to start it:
PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().
showView(REPL_PLUGIN_ID, project.getName(), IWorkbenchPage.VIEW_ACTIVATE);
Create a plug-in, implement the IConsole interface and add it using the ConsoleManager. Example code to start it:
ConsolePlugin.getDefault().getConsoleManager().addConsoles(myConsoles)
Since I already implemented the Console I favor to the View part. I am not reluctant to implement the IConsole (and all the other interfaces that are required), however, I just don't see the advantages of it.
The Eclipse ConsoleManager must be there for a good reason, what is it? What would be the main reason/advantage to use it?
What I have found so far:
Advantages of implementing IConsole:
Support for default console buttons[3]
Disadvantages of implementing IConsole:
No (default?) support of rich text editing
I tried to make this question as clear as possible, yet if I can elaborate/clarify anything just let me know in a comment.
The advantage is unified user experience. Eclipse has several generic views that users have become accustomed to: outline, properties, problems view, console etc. Imagine if everyone would add their own custom views instead of reusing existing ones. There would be an overflow of perspectives, each containing custom views for a specific task (or, alternatively, a single perspective crowded with custom views). So, if your console falls under the notion of console - task specific (text based) interaction containing only transient data - then you should probably implement your "view" as console.
As the previously quoted wiki entry says the console view is primarily intended for simple ports of traditional code which uses System.out.print and the like.
A few plugins such as the SVN and CVS code use the Console view to provide the traditional output from commands but also provide additional views and dialogs which provide more or better information.
So if you are developing an Eclipse plugin from scratch I would say you create your own view(s). Hopefully you can provide more actions for manipulating your data than are available in the Console view. If appropriate you could also provide the console view like SVN does.
From the Eclipse.org wiki:
When these tools are ported for use with an IDE, this console output is typically replaced with richer forms of feedback, such as views, markers, and decorations. However, users accustomed to the old command-line output may still want to see this raw output as an alternative to other visual forms of feedback. Tools in this category can use the Console view to write this output.
Prior to Eclipse 3.0, each plug-in that wanted console-like output created its own Console view. Eclipse 3.0 provides a single generic Console view that all plug-ins can write to. The view can host several console documents at once and allows the user to switch between different console pages.
Currently i am developing a CRM web applications using J2EE . For this application i need to support the localization for the layout such as menu names.
At the same time i need to allow admin to customize the layout such as adding new menu or deleting the menu and changing themes. I am planned to use XML for the layout specifications
Anyother methods to achieve this one?
Please help me .
Thanks in advance
Dilip
I think that If you use an XML you have to write your Parsers to read/write the settings updated by the users which will be time consuming and may be complicated.
I would suggest to use Database and put these Menus in master tables. Then you can create a table (for many to many relationship with menus and users) which contains the settings updated by the user. At the login or before generating the menus, you can get the menus specific to that user and display it as per your requirement. You can do the same for Themes.
I think, this would be bit easier and readable too.
What you want is Customization / Personalization, not Localization. Customization / Personalization involves a lot of work. There are special frameworks such as Oracle's WebCenter Framework that are proficient at this. If you get into writing this customization framework yourself, you will be developing and maintaining a lot of plumbing which will take time away from implementing real business functionality. I suggest that you do not re-invent the wheel and try to re-use an out of the box framework.
I'm working on a project, that requires forms on page to be divided and put into separate tabs. Apache Wicket have very nice and simple way to do tabs by itself (TabbedPanel class), but my concern is, that this solution rely on AJAX for loading the content of the panels, hence the only one part of the form would be submitted after user presses "Submit" button.
I found a solution for simple CSS/JS tabs (http://www.barelyfitz.com/projects/tabber/), but I feel uneasy to use third party solution, and it is complicating my project (also, I'm not sure about the license).
What should I do?
There are several impls of TabbedPanel with JQuery which are completely JS/CSS based.
See wicketstuff's jquery integration project and WiQuery project.
The default TabbedPanel doesn't use AJAX. To use Ajax there is a own implementation (AjaxTabbedPanel).
This sounds very much like a wizard to me. Since wicket provides a wizard component to handle this kind of use case this might be a good point to look. Since I've not yet used this component I don't know how far it can be taken to display tabs but if it can't, it might at least give you the idea on how to build your own with tabs.
I have a question on managing a multipage GWT website. For now I only have one html page in which I embed lots of divs to store the widgets that I use. Then, according to the user's actions I add or remove the necessary divs using GWTs DOM class. Therefore, I use only one html page to simulate multiple pages. Is there a better way to do this?
Thanks.
I disagree with cletus. In my experience, gwt is just as good at enhancing multipage apps as it is at one-page applications like gmail. It just depends on what you're requirements are for your web app.
I'd agree that writing one-page applications is definitely the place to start, but once you get the concept of gwt modules, they can easily be used to add custom javascript to multiple pages.
To answer your question; I think your design of using one page and swapping out widgets is perfectly acceptable.
These talks might help to give you ideas about when multi page apps might make sense:
Effective GWT: Developing a complex,
high-performance app with Google Web
Toolkit
Progressively Enhance AJAX
Applications with Google Web Toolkit
and GQuery
GWT is designed primarily for one-page applications. There is good reason for this. You take a hit every time you do a page transition with so much Javascript. The page load times are so noticeable. Think of goign to GMail. You have a period of 1-5 seconds where it loads. Now how would your user experience be if that happened whenever the user went to a new page and that happened a lot?
Neither do you need to put every widget on the page. You can dynamically create and add (or remove) widgets as you see fit. It's a somewhat different approach to how you'd normally do a traditional multi-page HTML-centric Website.
Something I have found useful is using the GWT DeckPanel. A deck panel is like a deck of cards where each "card" is a GWT Panel. You can treat these "card" panels like pages and initialise and populate them with widgets at startup. You can then respond to user navigation actions by bringing a "card" panel to the front of the deck so that the user can see it.
The sort of approach works best as part of either the MVC (model-view-controller) or MVP (model-view-presenter) design pattern.
In order to achieve such a thing, you should have history management - like Gmail, which can use back/forward. It is achieved by anchors, and this class
In addition to the good DeckPanel and History suggestions, I'd also add that you can get GWT to split your app into multiple JS files that are dynamically loaded as needed with runAsync. This let's you have a very fast initial page load and load the new "pages" as the user needs them.
LazyPanel.createWidget() is a convenient place to stick a runAsync call that can be combined with DeckPanel or TabPanel to dynamically load content and UI code. A controller/presenter for navigation is even better (though a little more work on the programmer sometimes).