Your SlideShare is downloading. ×
Should I Be Writing My Own Web Experience Factory Builder? TECH-D13 from IBM Exceptional Web Experience 2013
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Should I Be Writing My Own Web Experience Factory Builder? TECH-D13 from IBM Exceptional Web Experience 2013


Published on

TECH-D13: Should I write my own Builder? Increase productivity by identifying and capturing repeatable design patterns within Web Experience Factory …

TECH-D13: Should I write my own Builder? Increase productivity by identifying and capturing repeatable design patterns within Web Experience Factory

David Wade, Davalen’s Web Experience Factory Architect
Adam Kewley, Web Experience Factory Lead, Davalen

Description: Writing efficient code in a modular fashion is a fundamental concept in developing quality software that must grow and change as business dictates. Capturing key components for reusability enables your developers to capitalize on shared knowledge through proper use of repeatable design patterns. This session is geared towards IT managers, architects and developers who wish to not only learn how to properly capture design patterns in IBM Web Experience Factory (WEF), but when to spot the need for such mechanisms. Utilizing existing techniques and features within WEF to generate your own library of repeatable functionality. Only available at the IBM Exceptional Web Experience conference, learn from a seasoned lead architect with applicable world-class practical knowledge.

Some topics covered will include:

Breaking down code reuse: builders, models, ljo's (what is this...)
Identifying reuse areas at a project level
How to decide between a builder and a model
Other areas of code reuse (data retrievers, LJO's services)
Pitfalls to avoid

Published in: Education, Technology

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Today's discussion will be focused around code and resource reuse through various means in a given WEF project. There also may be some talk about builders. I'm not going to lead anyone on until the very end to answer the original question, so I'll start with a summary. Should I be writing my own builders? Possibly. I find that only about 10% of the time am I actually writing a builder. There.. mystery solved. You can get up and leave now if you'd like.   Builders can be very simple or very powerful. One could look a them as nuggets of modified and time tested code that may not fit your individual need 100% but will be (almost) guaranteed to run across multiple browsers and platforms, with a good deal of bugs shaken out.   Remember that when considering writing your own builder. If you're looking for the one-size fits all solution, there will be several aspects that you may be missing.    Writing new builders can introduce a whole new set of problems. Remember that when you go to think about writing one.
  •   #1 I need to do something that isn't easy to do otherwise in a model. For example. ***REPLACE*** builders actually allow you to modify the contents of a page during model generation. Data Page based builders may be modifying the schema or **INSERT** which is more convenient to do in a builder.     #2 People need to quickly implement some standard feature or fix that may require a complex UI. Using the coordinator class you can replace an imported model with a builder call editor that can be customized to your liking. The SpreadSheet import builder is a good example of that. After picking a spreadsheet you're given sheet names and other information to work with.     #3 A model based builder is becoming too complex to maintain. This is a rarity but a model based builder relies on profiling of various inputs and may be cumbersome to maintain if it grows too complex.     #4 Only out of preference I tend to write java-based builders more than model based builders. I've been doing it that way for years and it just seems easier to me. Your mileage may vary.     #5 I need to institute new functionality as a standard.. that others may use across projects (or on a large project) such as the IBM Email builder.     #6 I need to write something that may be included in a model more than once. It can be tricky to write an imported model module that can be imported multiple times. Using a java-based builder you can use custom names and ID's for your artifacts. ** is this true for model based?**     #7 Extending an existing builder. This is a fringe case, but there are certain times where you need to tack a bit of extra functionality on to a WEF builder. You can write your own builder which extends the original (even uses the same coordinator and cloned builder definition file), but utilizes a custom regen class. A similar technique was used at IBM for creating some of the atomic dojo builders (such as checkbox). The existing builders are time tested, so extending is a smart move. 
  • Transcript

    • 1. Click to add text Exceptional Web Experience 2013 Americas May 20 – 23, 2013 | Hilton Chicago ExceptionalWeb Adam Kewley Web Experience Factory Lead, Davalen © 2013 IBM Corporation TECH-D13 Should I be writing my own Web Experience Factory Builder?
    • 2. © 2013 IBM Corporation ExceptionalWeb 2 Introduction • Patterns are an important part of Web Experience Factory (WEF) projects. • In my experience custom builders are created 10% of the time. • Most builders are prototyped in a model before determining how to implement a reusable solution. • Consider other areas of code reuse first • Linked Models • LJO’s • Model Container • Templates/Base pages
    • 3. © 2013 IBM Corporation ExceptionalWeb 3 Overview • Introduction • Patterns (Code reuse) • Custom Builders • Identifying Patterns at the Project Level • Closing Thoughts
    • 4. © 2013 IBM Corporation ExceptionalWeb 4 Patterns: Imported Model • Imported models comprise roughly 50% of all code reuse in projects that I’ve been involved with. • Profiling inputs allow you to parameterize particular pieces of an imported model • Developers can easily create or edit them as needed • Allows you to override existing pages or methods • Testing can be a bit difficult, but there are methods to get around this. • Usually only imported once per portlet/model. Builders have an edge here. • Imperative for creating proper code standards and reusing common artifacts
    • 5. © 2013 IBM Corporation ExceptionalWeb 5 Patterns: Imported Model
    • 6. © 2013 IBM Corporation ExceptionalWeb 6 Patterns: Multi-Page Navigation
    • 7. © 2013 IBM Corporation ExceptionalWeb 7 Patterns: Common Model  Service Consumer  Common Variables  Events for each page Note: When this model is imported into each page you need to check the “Import once” box in the advanced section.
    • 8. © 2013 IBM Corporation ExceptionalWeb 8 Patterns: Controller Model  Imports Pages  Receives Events  Routes to Next Pages  Profile to Test Pages
    • 9. © 2013 IBM Corporation ExceptionalWeb 9 Patterns: Page Models  Imports Common  Encapsulated Functions  Fires Navigation Events
    • 10. © 2013 IBM Corporation ExceptionalWeb 10 Patterns: Linked Java Objects • LJO’s allow for the reuse of new or existing Java Code • Enables developers to make use of other company/project standards that may exist outside of WEF projects • Usually easy to identify whether a solution requires a builder or LJO. The areas of needs rarely overlap. • Utilize standards such as logging and event handling • Define constants for manipulating WEF artifacts
    • 11. © 2013 IBM Corporation ExceptionalWeb 11 Patterns: Model Container • Act like individual portlets within an existing model • Encapsulated model instances that act outside of the context of the parent model • Useful for reusing large pieces of functionality across a project • Communicate via events • Parent model can reload, instantiate with new data, or control profiling information
    • 12. © 2013 IBM Corporation ExceptionalWeb 12 Patterns: Other • HTML Templates, base Pages, customizable Themes, RDD files, default configurations, standard JS includes, profile sets and base models enable architects to set standards for unified design • Extended base classes that IBM provides. For example; custom selection handlers or custom paged data retrievers • Template reuse also enables architects to roll out project-wide changes (or bugfixes) as needed without having to make individual changes in each model/portlet. • IBM recommends creating your own instances instead of modifying the base template files.
    • 13. © 2013 IBM Corporation ExceptionalWeb 13 Custom Builders: Page Automation
    • 14. © 2013 IBM Corporation ExceptionalWeb 14 Custom Builders • Most complex code reuse mechanism within WEF • Very useful for allowing other developers to easily implement common functionality that can interact with other builders and profiles within WEF. • Can be added to a model more than once (usually) • Generating API allows other builders to call your builder programmatically • Builders can be either Model or Java based. • Can be setup to work across multiple projects as well.
    • 15. © 2013 IBM Corporation ExceptionalWeb 15 Custom Builders: When to create? • To perform an operation that is difficult to do in a model: • Data Page and Page modification builders • Builders that modify schema or other builders • The common functionality requires a complex UI to properly configure. Coordinator class excels in this case. • Spreadsheet Import • To establish standards that may be used across multiple projects. • IBM email builder • When a piece of functionality may be inserted to a model (or page) multiple times. • Generate or manipulate artifacts that interact with WEF standards. • Custom data retriever.
    • 16. © 2013 IBM Corporation ExceptionalWeb 16 Custom Builders: Model vs Java based • Model-based • builders are combinations of existing builders • easier to implement • Converting a prototype model to a model based builder is not that difficult • do not require custom regeneration or coordinator classes to construct • Java-Based • allow you to write custom code • can operate in multiple regeneration phases. • Some builders use their own base classes which cannot be used by model based builders
    • 17. © 2013 IBM Corporation ExceptionalWeb 17 Custom Builders: Generation
    • 18. © 2013 IBM Corporation ExceptionalWeb 18 Custom Builders: Generation In general this is a sequential invocation of builder calls in a model For each builder call: •Look up the builder definition from ID in builder call, and find the builder's class name •Invoke the builder's generation class, passing the inputs defined in the builder call At design time, regen occurs whenever a change is made to the model On the server, regen occurs as needed to support the dynamic profiling features of Experience Factory
    • 19. © 2013 IBM Corporation ExceptionalWeb 19 Custom Builders
    • 20. © 2013 IBM Corporation ExceptionalWeb 20 Custom Builders – Regeneration Phases Builders can request which phases they want to be called in 1.PHASE_CONSTRUCTION – initial object creation This is where builders can specify additional phases to be called in 2.Page Automation builders run at the end of PHASE_CONSTRUCTION, after all other builders 3.PHASE_POSTCONSTRUCTION – Control builders add elements to pages 4.PHASE_MODIFICATION – For modifying elements 5.PHASE_VALIDATION – Validation 6.PHASE_PROCESS – Available for final processing 7.PHASE_EXTERNALIZE – Write files if necessary (in Factory, used only by Service Stub builder)
    • 21. © 2013 IBM Corporation ExceptionalWeb 21 Custom Builders: Pitfalls • Most imported model code reuse allows for a single instance of the model per portlet. • Users may add your builder to their model multiple times. • Builders may be attached to pages or used in ways that were not forseen originally. • Java-based builders have a decent learning curve. • Builder errors (generation, coordinator) may be confusing to end user. • Page location and duplicate ID tags can plague a project if not planned for properly • Ensuring the UI is easy to use by the end user
    • 22. © 2013 IBM Corporation ExceptionalWeb 22 Custom Builders: Overview A discrete bundle of functionality in the construction of a WebApp Of the builders that are supplied in IBM® Web Experience Factory, some are primitive and do very simple things, like adding a page to the WebApp, or putting a button on a page. Others are complex, and can construct an entire form along with the Java code required to move data between the form and a variable. There are three critical pieces to a builder. • Builder Definition file (bdef) • Builder class • Coordinator class (optional)
    • 23. © 2013 IBM Corporation ExceptionalWeb 23 Custom Builders: Overview
    • 24. © 2013 IBM Corporation ExceptionalWeb 24 Custom Builders: Builder Definition (bdef)  Xml descriptor for builder. Contains information about builder inputs, metadata, and class/model information.  Defines how to invoke it and how to display instances of it  IBM base builders are a wealth of information for adding various inputs and customizing them.  Bdef defines the UI makeup of the builder.
    • 25. © 2013 IBM Corporation ExceptionalWeb 25 Custom Builders: Generation Class  Generation (Regen) class performs the regen time work for java- based builders.  Adds artifacts to the webapp  Invokes other builders  Modifies page, schema, or datapage layout (if needed)  Operates during one or more regeneration phase  Utilizes multiple base classes to provide various mechanisms for builder creation.  Defines constants for builder inputs and helper methods/classes.  Provides mechanism for reporting regen errors.
    • 26. © 2013 IBM Corporation ExceptionalWeb 26 Custom Builders: Coordinator Class Optional class for creating complex UI’s Required when animating builder call editor. Simplifies development for users. For example reading configuration files, or populating drop down lists with relevant data.
    • 27. © 2013 IBM Corporation ExceptionalWeb 27 Custom Builders: Additional Artifacts Regen class may produce additional artifacts in the webapp. Helper Classes (LJO’s) allow the builder to share inputs and data with the helper class so that the builder may access these values at runtime. Base pages, imported pages, models, can be imported which may be used by the builder. Additional objects such as variables can be created that offer runtime values to the user (which may change). Example: javascript click action name.
    • 28. © 2013 IBM Corporation ExceptionalWeb 28 Custom Builders: Considerations • Start with a prototype model that tests the concept. *Note this may not work for page/schema modifier builders. • Identify the need for a builder, and determine the audience and if it could be used across multiple projects. • Decide upon whether to use a model or java based source for your builder. • Consider a coordinator class (if a complex UI is needed) • Determine helper artifacts • Ensure builder behaves well in different scenarios. • Test against various pitfalls described earlier.
    • 29. © 2013 IBM Corporation ExceptionalWeb 29 Custom Builders: Some examples • Custom functionality to one or more portlets. • PDF export with custom dialog for example. • Passing Parameters with a Portal URL • Modifying multiple elements on a page. One-off builders that perform a complex operation on existing builders or content). • Custom collapsible section on datapage. • Modifying schema or datapage layout. • Data Field Settings builder
    • 30. © 2013 IBM Corporation ExceptionalWeb 30 Custom Builders: Some examples • General Common code. • XML to JSON converter builder.html • Make use of WEF DataService SOA architecture by creating a standardized builder. • New backend datasource builder.
    • 31. © 2013 IBM Corporation ExceptionalWeb 31 Identifying Patterns at the Project Level • Efficiently managed projects require architect to have ground level knowledge of inner workings of project. • Identifying areas of code reuse early on will help standardize features, prevent code duplication, and allow for fixes/changes to be propegated quicker. • Work with senior developers to identify areas that may be suited to code reuse or standardization • Fair amount of code reuse comes later on in the development cycle if pieces are not meshing together well, or requirements change.
    • 32. © 2013 IBM Corporation ExceptionalWeb 32 Closing Thoughts • Code reuse is an important cornerstone in a properly managed WEF project • Builders are but a small piece of many other facets of code reuse and standardization • Identifying these areas early on will help set a strong foundation for standardization and a mentality of modularity. • Working with senior developers and identifying areas of code reuse as project progresses is important • Identifying requirements that may be cross-project is a good candidate for creating builders. • Creating a builder is more difficult than just throwing together a model, especially if it’s intended to be used elsewhere.
    • 33. © 2013 IBM Corporation ExceptionalWeb 33 Closing Thoughts (Continued) • Look for sample builders provided by IBM. Many of these are quite useful • Follow WEF/IBM standards when creating a builder. This allows for seamless integration within the product. • Use the Builder Skeleton builder for java-based builders. • Model based builders are a preferred place to start.
    • 34. © 2013 IBM Corporation ExceptionalWeb 34 Links • Tips and tricks for writing your own Java-based Builders based-builders/ • Extending Web Experience Factory with Custom Builders • Creating reusable patterns with Imported Model and profiling http://www- ofiling • Documentation on making custom builders lookupName=Web+Experience+Factory+8+Documentation#action=openDocu ment&res_title=Creating_a_custom_builder_wef8&content=pdcontent • Leveraging the Model Container Builder http://www- • 
    • 35. © 2013 IBM Corporation ExceptionalWeb 35 Links • Making a custom builder tutorial • Custom builder samples http://www- #Making+builders • Model-based builder sample http://www- el_and_profiling • Creating a feature set • BuilderDef documentation lookupName=Web+Experience+Factory+8+Documentation#action=openDocu ment&res_title=Builder_definition_structure_wef8&content=pdcontent
    • 36. © 2013 IBM Corporation ExceptionalWeb 36 We appreciate your feedback. Please don’t forget to fill out your evaluation. Thank you for joining us! g my own Web Experience Factory Builder? valen
    • 37. © 2013 IBM Corporation ExceptionalWeb 37 For More Information Tips and tricks for writing your own Java-based builders Resources and samples for custom based builders 8e33fc67f50e/entry/new_resources_and_samples_for_custom_builders?lang=en Extending WEF with custom builders Tutorial on creating custom builders topic=/com.bowstreet.designer.doc/tutorials/Custom_Builder_Introductory_Tutorial.htm
    • 38. © 2013 IBM Corporation ExceptionalWeb 38 For More Information IBM Customer and Employee Experience Suite, WebSphere Portal and Web Content Manager Software and Solutions WebSphere Portal and IBM Web Content Manager Information Center WebSphere Portal and Web Content Manager Version 8 Reviewer's Guide IBM Web Experience Fast Track Offerings WebSphere Portal and Web Content Manager Business Solutions Catalog
    • 39. © 2013 IBM Corporation ExceptionalWeb 39 © IBM Corporation 2013. All Rights Reserved. The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software . References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here. Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. ries in the United States and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others. All references to OpenFinancial, Greenwell and Open Bier refer to a fictitious company and are used for illustration purposes only.