WebSphere Portlet Factory - Things I Did Not Know

As mentioned, my knowledge of WPF has increased in leaps and bounds as I progress through the course ( and this is the 3-day introduction; I've the 1-day advanced course to come tomorrow ).

Imported models seem pretty cool - think of it this way: -

Developer A works on the back-end integration, using direct database/application access or, more likely, a services layer ( whether using web services or not ). This results in a model.

Developer B works on the front-end user interface, applying Web 2.0-like artifacts such as Ajax, Dojo etc. as well as CSS, JSF, JSP etc. This results in a model.

Developer C ( or the architect, which would be me me me ) ties the two models together; for example, he/she creates a third model which is, effectively, the application/portlet framework, and simply imports the other two models into it.

At this stage, all of the builder calls in both imported models are available for Developer C to use, without needing to be bothered about the actual implementation e.g. JDBC vs DAO, JSF vs JSP, Ajax vs Dojo etc.

This provides the ultimate abstraction - if the mechanism of data access changes in the future ( from JDBC to WSDL ), Developer A changes their model, and Deveoper C re-imports it.

The other big revelation was profiling - I kinda knew how powerful this way, especially as I've seen it demonstrated so many times. However, I'd never actually used it.

In essence, Developers A and B both identify builder inputs that can be profiled ( can relate to different use cases ), and associates those inputs with a specific profile set/profile.

The application assembler ( Developer C ) creates/manages the profile, entering the appropriate values for each profiled builder call.

This allows one "application" to be generated for each use case, based on the inputs to the profile. A profile could then be selected by the end-user, or mapped to a LDAP group.

Want to change the way the sales team use/see the CRM application ? Simply change the profile, rather than going back to Developers A and B.

It's possible to introduce muchos complexity at this stage, but there is an art to keeping it simple.

All in all, a good investment of my time thus far .......

Watch this space