Skip to main content

Home/ Java Development/ Group items tagged fun

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Merit Campus

Coding is fun - 0 views

Learn Java programming

shared by Merit Campus on 05 Dec 14 - No Cached
  • Merit Campus on 05 Dec 14
     
    #Programmers do not #code for money. They do it because it's fun.
abuwipp

Spring to Java EE - A Migration Experience | OcpSoft - 0 views

ocpsoft.com/...tion-guide-cdi-jsf-jpa-jta-ejb

jee6 migration spring javaee

shared by abuwipp on 05 Oct 10 - No Cached
  • Hendy Irawan on 05 Oct 10
     
    Does it all make sense now? Do you know how to solve every problem? Probably not, but when it comes right down to it, using Java EE can be even simpler than using Spring, and take much less time. You just have to find the right guides and the right documentation (which is admittedly a severe sore-spot of Java EE; the documentation is still a work in progress, but is getting much better, save blogs like this one.) You have to turn to a vendor like JBoss, or IBM in order to get the use-case driven documentation you need, and they do have documentation, it's just a matter of finding it. Seam 3 in particular strives to give extensive user-documentation, hopefully making things much simpler to adopt, and easier to extend. The main purpose of this article was not to bash Spring, although I may have taken that tone on occasion just for contrast and a little bit of fun. Both Spring and Java EE are strongly engineered and have strong foundations in practical use, but if you want a clean programming experience right out of the box - use Java EE 6 on JBoss Application Server 6 - JBoss Tools - and Eclipse. I will say, though, that the feeling I've gotten from the Spring forums vs the Java EE forums, is that there are far many more people willing to help you work through Java EE issues, and more available developers of the frameworks themselves to actually help you than there are on the Spring side. The community for Java EE is much larger, and much more supportive (from my personal experience.) In the end, I did get my application migrated successfully, and despite these issues (from which I learned a great deal,) I am still happy with Java EE, and would not go back to Spring! But I do look forward to further enhancements from the JBoss Seam project, which continue to make developing for Java EE simpler and more fun. Don't believe me? Try it out. Find something wrong? Tell me. Want more? Let me know what you want to hear.
Prajot G.

Caching with EhCache - Part II « Plain Old Java Fun - 0 views

balamaci.wordpress.com/...cachingehcachepart2

caching java

shared by Prajot G. on 02 Nov 12 - No Cached
  • Prajot G. on 02 Nov 12
     
    SelfPopulatingCache,Cache refresh
anonymous

Large scale application development and MVP - Part II - Google Web Toolkit - Google Code - 0 views

code.google.com/...mvp-architecture-2.html

shared by anonymous on 18 Jan 11 - Cached
  • itself
    • anonymous
      anonymous on 18 Jan 11
       
      The View Implementation
  • @UiHandler("
  • presenter.onAddButtonClicked();
  • ...91 more annotations...
  • onAddButtonClicked
  • eventBus.fireEvent(new AddContactEvent());
  • presenter needs to know more about the view
  • view needs to know more about the data model
  • data types are typically homogeneous within column borders
  • ColumnDefinition abstract class
  • houses the any type-specific code (this is the third party mentioned above)
  • ColumnDefinition
  • ColumnDefinition(s) would be created outside of the presenter
  • we can reuse its logic regardless of what view we've attached ourself to
  • update our views such that we can set their ColumnDefinition(s).
  • setColumnDefinitions
  • this.columnDefinitions = columnDefinitions;
  • so that we can pass in
  • a mocked ContactsView instance when testing our ContactsPresenter
  • in our AppController, when we create the ContactsView,
  • new ContactsViewColumnDefinitions().getColumnDefinitions();
  • we can initialize it with the necessary ColumnDefinition(s).
  • contactsView.setColumnDefiniions(
    • anonymous
      anonymous on 19 Jan 11
       
      Initialize ContactsView with the necessary ColumnDefinition(s)
  • With our ColumnDefinition(s) we can pass the model untouched.
  • As mentioned above we were previously dumbing down the model into a list of Strings
  • current solution
  • List<String> data
  • display.setData(data);
  • how that data type is rendered.
  • use generics
  • third party that abstracts
  • knowledge of a cell's data type
  • stringing together a list of these classes
  • providing the necessary render()
  • and isClickable()/isSelectable() override
  • ContactsViewColumnDefinitions<ContactDetails>
  • columnDefinitions =      new ArrayList<ColumnDefinition<ContactDetails>>()
  • ColumnDefinition<T>
  • ContactsPresenter
  • ContactsViewImpl
  • ColumnDefinition<T> columnDefinition = columnDefinitions.get(j);
  • the presenter can pass the model untouched
  • the view has no rendering code
  • that we would otherwise need to test. And the fun doesn't stop there.
  • presenter.onItemClicked(
  • presenter.onItemSelected
  • ClickEvent
  • cell.getCellIndex()
  • columnDefinition.isClickable()
  • SelectEvent
  • columnDefinition.isSelectable()
  • return shouldFireClickEvent;
  • return shouldFireSelectEvent;
  • respond to user interaction in different ways based upon the cell type that was clicked
  • use them for rendering purposes
  • defining how to interpret user interactions
  • we're going to remove any application state from the ContactsView
  • replace the view's getSelectedRows() with a SelectionModel
  • The SelectionModel is nothing more than a wrapper around a list of model objects.
  • ContactsPresenter holds on to an instance of this class
  • onItemSelected
  • Having the ColumnDefinition create a new widget for each cell is too heavy
  • Replace our FlexTable implementation with an HTML widget
  • calling setHTML()
  • Reduce the event overhead by sinking events on the HTML widget
  • rather than the individual cells
  • update our ContactsView.ui.xml file to use a
  • HTML widget rather than a FlexTable widget.
  • <g:HTML ui:field="contactsTable">
  • Inefficiencies related to inserting new elements via DOM manipulation Overhead associated with sinking events per Widget
  • for each item ask our column definitions to render accordingly
  • each column definition
  • render itself into the StringBuilder
  • rather than passing back a full-on widget
  • calling setHTML on a HTML widget
  • rather than calling setWidget on a FlexTable.
  • This will decrease your load time, especially as your tables start to grow.
  • we're reducing the overhead of sinking events on per-cell widgets
  • instead sinking on a single container
  • ClickEvents are still wired up via our UiHandler annotations
  • get the Element that was clicked on
  • and walk the DOM until we find a parent TableCellElement
  • we can determine the row
  • shouldFirdClickEvent() and shouldFireSelectEvent()
  • to take as a parameter a TableCellElement rather than a HTMLTable.Cell.
  • faster startup times via Code Splitting.
  • runAsync() points
  • split portion of your code is purely segmented
  • not referenced by other parts of the app
  • it will be downloaded and executed at the point that it needs to run
  • Do we really want to download all of that code before the user even logs in?
  • Not really.
  • simply grab the login code, and leave the rest for when we actually need it
  • wrap the code that creates the ContactsView and ContactsPresenter in a runAsync() call
  • as optimizations such as this one become easier and easier to implement.
1 - 5 of 5
Showing 20▼ items per page