Thursday, 11 October 2007
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
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
# posted by Dave Hay : 06:35
Subscribe to Posts [Atom]
