The following is a re-post of the "Cloning your Corporate UI with HTML DB" series that I blogged about back in 2005 on the now-defunct Orablogs site. Most of the content and advise is still the same today, and has been reposted here exactly as it was on the old site. Enjoy!
June 8, 2005
I've often been asked how to create custom Themes & Templates with Oracle HTML DB. The truth is that it’s one half Art, and one half Science. (Note: Percentages may vary based on what you consider “Art” and “Science”). And since the desired look and feel varies from site to site, there’s no easy way to document these steps.
Thus, I am going to attempt to “blog” my way through it, using a real-world example.
As you may know, the look & feel of oracle.com was recently updated as part of the re-launch of oracle.com, OTN, etc. I believe that this is now the 4th UI in 2 years for oracle.com.
Three sites that I manage - Oracle HTML DB Studio, Oracle HTML DB References, and Best Practices PL/SQL – are running in the previous “livery”, and need to be updated. I figured that this is as good an example as any to illustrate how to change the look & feel of an HTML DB application without changing the underlying functionality.
Like any good craftsman, you need good tools in order to do a good job. (Hint: never buy the cheapest ANYTHING at Home Depot – it will break, and then you will end up re-buying the more expensive one anyways) Here’s what I plan on using:
Since it gets the most traffic of the three, I am going to use HTML DB Studio as the baseline application. Truth be told – it really doesn’t matter which one I use, as once I have my theme completed, I can apply it to all three.
As a first step, I exported HTML DB Studio and then re-imported it as a new application. This way, the production site won’t reflect any of my changes until I am completely done. Feel free to pop in on the Work in Progress.
The next step is to determine which Templates in my Theme will need to be re-worked. Overall, I have 33 templates in my oracle.com FY06 Theme. If you navigate to this page:
Workspace HTML DB STUDIO > Builder - Application 20530 > Shared Components > Themes > Templates > Template Utilization
You can see which of your templates are actually being used by a specific application. In my Theme, there are 13 templates which are not used. Thus, I need to initially only be concerned with the 20 which are referenced, as the “unused” 13 may be referenced in another application. Either way, this reduces the amount of work required.
Now that I have a short list, I’m going to try to make it even shorter. In some cases – such as my button template – I will not need to make any changes, as the template will look OK in both the new and old UI’s. I can further reduce my list by one or two more templates here. Sometimes you’ll be able to do better…
Where to Start
I’ve found that the best place to start is with the Page Template. Replicating the structure of your desired UI makes assembling all of the components that much easier. Unfortunately, this is typically the most time-consuming task, as Page Templates can be rather large. Depending on how much the target page differs from your current page, you’ll need to decide whether to try to retrofit it or start from scratch. Since it looks like the new oracle.com look is simpler than the previous one, I am going to start from scratch.
An Oracle HTML DB Page Template is nothing more than HTML sprinkled with HTML DB-specific tokens, used to substitute sub-templates and/or values. Thus, you could go to oracle.com, save the HTML Source, paste it into an HTML DB Page Template, and the results should be similar, save the relative image & CSS references which would break. That’s exactly what I’m going to do!
Uh-oh:
Your browser sent a request that this server could not understand. mod_plsql: /pls/otn/wwv_flow.accept HTTP-400 Value param too long. Length is 43467. Upper limit is 32512
Looks like I need to slim down the code, as I am around 10k over the 32k limit. I’ll take that same source and paste it into DreamWeaver, and then remove any content. Remember, we’re just trying to build the structure of the page – we’ll use HTML DB Regions to populate the page with content.
Cutting out all of the content from the center region of the OTN Home page got us well under the 32k limit. I also took a couple of minutes and ensured that the token #BOX_BODY# was placed in the newly-empty center region. #BOX_BODY# will be substituted with the HTML DB Regions for a specific page – reports, forms, HTML, PL/SQL, etc.
Next, let’s set the Theme to use our new Page Template as the Default Page Template. From the Themes page, click on the edit icon next to your Theme, and then select your Page Template as the default Page Template and Apply Changes. If pages in your application are set to use the Default Page Theme, then you should instantly see the new Theme in action – as ugly as it may be.
I’ll have to say that this was the BEST first draft that I have seen in a while:
However, we’re a long way from being done, as things like Authentication, Tabs, Region Templates, CSSs, and Lists still need to be translated over.
Continue to Part II
June 8, 2005
I've often been asked how to create custom Themes & Templates with Oracle HTML DB. The truth is that it’s one half Art, and one half Science. (Note: Percentages may vary based on what you consider “Art” and “Science”). And since the desired look and feel varies from site to site, there’s no easy way to document these steps.
Thus, I am going to attempt to “blog” my way through it, using a real-world example.
As you may know, the look & feel of oracle.com was recently updated as part of the re-launch of oracle.com, OTN, etc. I believe that this is now the 4th UI in 2 years for oracle.com.
Three sites that I manage - Oracle HTML DB Studio, Oracle HTML DB References, and Best Practices PL/SQL – are running in the previous “livery”, and need to be updated. I figured that this is as good an example as any to illustrate how to change the look & feel of an HTML DB application without changing the underlying functionality.
Like any good craftsman, you need good tools in order to do a good job. (Hint: never buy the cheapest ANYTHING at Home Depot – it will break, and then you will end up re-buying the more expensive one anyways) Here’s what I plan on using:
- Mozilla Firefox w/these extensions:
- Web Developer
- ColorZilla
- ieview
- DreamWeaver MX
- PaintShop Pro
Since it gets the most traffic of the three, I am going to use HTML DB Studio as the baseline application. Truth be told – it really doesn’t matter which one I use, as once I have my theme completed, I can apply it to all three.
As a first step, I exported HTML DB Studio and then re-imported it as a new application. This way, the production site won’t reflect any of my changes until I am completely done. Feel free to pop in on the Work in Progress.
The next step is to determine which Templates in my Theme will need to be re-worked. Overall, I have 33 templates in my oracle.com FY06 Theme. If you navigate to this page:
Workspace HTML DB STUDIO > Builder - Application 20530 > Shared Components > Themes > Templates > Template Utilization
You can see which of your templates are actually being used by a specific application. In my Theme, there are 13 templates which are not used. Thus, I need to initially only be concerned with the 20 which are referenced, as the “unused” 13 may be referenced in another application. Either way, this reduces the amount of work required.
Now that I have a short list, I’m going to try to make it even shorter. In some cases – such as my button template – I will not need to make any changes, as the template will look OK in both the new and old UI’s. I can further reduce my list by one or two more templates here. Sometimes you’ll be able to do better…
Where to Start
I’ve found that the best place to start is with the Page Template. Replicating the structure of your desired UI makes assembling all of the components that much easier. Unfortunately, this is typically the most time-consuming task, as Page Templates can be rather large. Depending on how much the target page differs from your current page, you’ll need to decide whether to try to retrofit it or start from scratch. Since it looks like the new oracle.com look is simpler than the previous one, I am going to start from scratch.
An Oracle HTML DB Page Template is nothing more than HTML sprinkled with HTML DB-specific tokens, used to substitute sub-templates and/or values. Thus, you could go to oracle.com, save the HTML Source, paste it into an HTML DB Page Template, and the results should be similar, save the relative image & CSS references which would break. That’s exactly what I’m going to do!
Uh-oh:
Your browser sent a request that this server could not understand. mod_plsql: /pls/otn/wwv_flow.accept HTTP-400 Value param too long. Length is 43467. Upper limit is 32512
Looks like I need to slim down the code, as I am around 10k over the 32k limit. I’ll take that same source and paste it into DreamWeaver, and then remove any content. Remember, we’re just trying to build the structure of the page – we’ll use HTML DB Regions to populate the page with content.
Cutting out all of the content from the center region of the OTN Home page got us well under the 32k limit. I also took a couple of minutes and ensured that the token #BOX_BODY# was placed in the newly-empty center region. #BOX_BODY# will be substituted with the HTML DB Regions for a specific page – reports, forms, HTML, PL/SQL, etc.
Next, let’s set the Theme to use our new Page Template as the Default Page Template. From the Themes page, click on the edit icon next to your Theme, and then select your Page Template as the default Page Template and Apply Changes. If pages in your application are set to use the Default Page Theme, then you should instantly see the new Theme in action – as ugly as it may be.
I’ll have to say that this was the BEST first draft that I have seen in a while:
However, we’re a long way from being done, as things like Authentication, Tabs, Region Templates, CSSs, and Lists still need to be translated over.
Continue to Part II
Comments