Planning a Scala based WCS framework

With this post I am starting to collect ideas about developing an Open Source Scala based development framework for WCS, tentatively named ScalaWCS. I am making public my intention in order to collect suggestions, critiques and, why not?, collaborators.

The rationale behind this idea is my desire (and I do not think I am alone) to  modernise a bit WCS development .

I do all my  work outside Fatwire/WCS in Scala. I love Scala a lot  and I want to use it for Fatwire coding as well. Here I  collected my ideas so far for this framework. I would really like to hear from you what you think.

Warning: the rest of this article will be hard to read for anyone who does not know Scala. Apologies for this. Maybe the number of developers is really small but Scala is really an exciting and powerful language and it is worth every minute you spent on it.

Move Away From JSP

The main goal of this framework is moving away from JSP.  I would like to to do all the coding in Scala instead.

JSP are really meant to be used only as a presentation layer, but in Fatwire you end up to do much more than this in JSP, and it is not very nice.

Of course JSP are actually part of Fatwire, there is no direct replacement for them you cannot get rid of them. But you can use them as a stub to call your Scala code.

The initial, rough idea is that you will keep Templates and CSElement, but the body of a template will be simply something like this

<% wcs.Dispatcher.dispatch(ics); %>

(automatically generated configuring the default template ). You are not expected to code anything else.

So, what will replace JSP?

Scala based templates

The real code will be written in Scala and will be something like this:

package article

object Layout extends Template {
    def apply(ics: ICS, c: String, cid: Long) =
      <h1>{ "title"! }</h1>
      <p>{ "body"! }</p>
 }

Instead of writing JSPs you use for rendering a method written in Scala.  For template coding,  I am leveraging the embedded xml literals available in Scala.

Furthermore, I am going to leverage the powerful Scala syntax, that will allow me to write "title"!  instead of ics.GetVar("title").

I understand there are some problems with this approach, mostly on  development and deployment. More on this later.

Nice wrapper on Fatwire API

Using Scala, I plan to wrap all the existing Fatwire tags with Scala calls. Something like

<asset:load name="thePage" type="Page" objectid="<%=ics.GetVar("cid")&>"/>
 <asset:get name="thePage" field="id" output="id"/>

will be available as a Scala call (using named parameters) like:

asset.load(name="thePage", type="Page", objectid= ("cid"!))
asset.get(name="thePage", field="id", output= "id")

This is however only the first step. The API will leverage some common elements in the API to be able to do

val thePage = asset.load("Page", "cid"!)
val id = thePage("id")

Each element will be functional and will return objects with appropriate methods allowing to extract fields using the apply syntax. A lot of work will be done on making  the API as nice as possible

It would be nice also to be able to keep the tag based syntax in the XML literals.

This should be possible, however the xml literals are not compiled in Scala, while they are in JSP.

A simpler implementation is possible just interpreting them when generating the  output. A more advanced implementation could be generating actual Scala code. This is more difficult to implement since it needs to leverage either a compiler plugin or a Scala macro.  Advantages and disadvantages will have to be carefully considered.

Real Unit testing

Once we moved away from JSP, the biggest advantage of using this approach is the possibility to perform real unit testing. Any unit test framework can be used, either ScalaTest or Specs2.

Because real code will live outside of WCS it will be possible to test it before deploying. However the framework will have to provide mocks in order to simulate the WCS environment.

This is an important feature.

Router {
   def name2id(name: String) = /* map a name in an id */
   def apply(components: List, param: Map ) components match {
       case Nil => Map( "c" -> "Page", "cid" -> name2id("Home"))+params
       case cid :: Nil => Map( "c" -> "Page", "cid" -> name2id(cid))+param
       case c :: cid :: Nil => Map("c" => c, cid -> name2id(cid)) + params
   }
}

Cheap research papers around the internet ones handiest method to pick up essays

Many students or maybe learners as a rule shortage plenty of time and the time and effort required in putting together a thorough examine- located document. A lot of university students are www.researchpaperkingdom.com/cheap-research-papers more likely to delay their particular jobs and therefore, tasks starts up piling up with their workstations. At publishing system we can assist you with each individual element of your terminology groundwork papers despite the area or maybe your academic degree. Somethings wrong with your academic papers if things at school are not going well. It is actually basic in which article writing responsibilities comprise a significant an area of the research assignments in school, university or college. According to their results students write a lot and are evaluated. That is why if you have nothing to write, you need to ask the professionals at writing srtvice for a professional assistance.

Strategy to pick professional cheap research paper coming up with facilitate for pupils

Business or marketing article, you are in the right place to have a chance to catc, if you are searching for the help with an academic researchh on top of it. When you feel you cannot cope with the thorough research dedicated to the chosen topic on efforts and it a couple of times before posting it, our own customised producing service is the best place to ask about for a few immediate and also affordable aid. It should cease being unexpected in which bargain research records are possible to seek out alongside absolutely free other, topics and samples priceless junk.

The new WCS User Interface

The new  Oracle-branded WecCenter Sites v11g is not a revolutionary product: it is still recognizable as the old, good ContentServer (formerly Fatwire, Divine and OpenMarket) we already know.  Nonetheless, in this new incarnation it looks like a big jump forward.

This release is probably defined more from what has been removed than from what has been added. Most of  the work done  on WCS looks to be a great effort to simplify, make uniform and consistent,  overall improve the user experience of the product. The first and more evident feature gone is the dash interface (but not its functionalities). It is also gone the insite interface,  but again,  insite editing is now even more powerful.

There is no more the dualism of 3 competing user interface (dash, advanced and insite), where you can do more or less the same thing in different incarnations. Instead, there is now one unified UI. It acts like the old Advanced interface when it comes to manage "advanced" content assets (mostly used by developers and webmasters) . The UI also acts like the dash interface to browse and edit content, but seamlessly integrates  insite editing to preview and edit content at the same time.

Let's do a walkthrough with screenshots to  understand better.

The Administrative interface

Let's start from the administrative (the old avanced) interface. It is now probably  going to be the less used but we start from it because it is familiar to the vast majority of current users.

On the top of the screen there is now a toolbar allowing to select the interface (now there are 2, the administrative and the contributor). If we select the administrative interface, as below:

It is now possible to create and search assets, but, important new, ONLY administrative assets: templates, cselements, attributes, definitioins and so on. It is no more possible create and edit content assets from this interface.

Creating an asset is still done in the old way. For example clicking on a start menu link to create a new template:

then the usual form is shown:

nothing new under the sun regarding the administrative assets (except a css restyling). The interesting parts comes now.

 The Contributor interface

When we select the new Contributor Interface things start to became new (and interesting):

Creating a new element now requires you select it from the menu. The new  action  now appears in a pull down menu:

Content can be edited now in a form, so in a sense it is still possible to do form oriented content editing. See below and please note the toolbar of saving, approving , previewing and deleting.

Understanding cache dependencies

WC Sites  (formerly Fatwire ContentServer) is a content oriented CMS, as opposed to other page oriented CMS. The exact meaning of being driven by the content is that you are required only to describe your content without considering how this content will be actually rendered .

This idea has a few consequencies that must be taken in appropriate consideration when you design and code a WCS implementation.

(Well this is not actually totally true, considering insite editing, that is a presentation oriented technology, however it does not change the concept - content and presentation are separated but related).

The relation between presentation and content

To better explain the problem consider a generic content, let's say an article in your site.

On the CMS you want to add it usually just once, but on the site the same article can appear a number of times in different web pages, in different formats.

For example an article can be displayed as a full text in a web page, as a summary in another web page or just as a simple link in many others.

All those occurrencies appears in different web pages, and you have to update  all of them when the underlying content model changes. For this reason WCS stores in the database dependency informations.

The main reason to keep those informations is because they are needed for an easy and efficient updating of the cache when the content changes.  In fact, when the site is rendered, blocks of html  (conventionally called pagelet) are generated from the content model and usually cached.

For each of those  pagelet a dependency is generated and stored. 

When the content model is changed all the stored dependencies are walked through and the dependent pagelets are invalidated and regenerated.

 In practice

You can see all of this in action simply inspecting the table SystemItemCache. This table is somewhat obscure but it keeps one of the more important informations used in publishing: dependencies between assets and pagelets.

This table is calculated while rendering the content model in an actual live site. Many dependencies  are actually calculated by the render:calltemplate. When you call a template, you are also declaring that a new pagelet (the one that will be rendered by the template you are invoking) will depend on the asset specified by c and cid. So a new dependency will be recorded for this asset.

Dependencies can also be recorded explicitly using the render:logdep tag. Indeed, you may notice that when you create a new template, some code involving a logdep is automatically added.

That code should NOT be removed: it is adding a dependency between the template itself (the code generating the pagelet) and the generated pagelet. Obviously, when you change the code generating the pagelet, that pagelet must be regenerated.

In general, a pagelet rendering a given asset (identified by c and cid) depends always on the asset itself (so a c:cid dependency is required) and the template that render it (so a Template:tid dependency is also required).

However things can became much more complex than this. There are other sources of dependencies: for example searchstate calls usually generate some dependencies, and an index gathered by a search can depend on so many assets that... an  "unknown dep" can be generated.

Those special dependencies basically invalidate each pagelet when any asset of a given type changes.

Common Errors

Unfortunately, caching and even worse dependency management are often misunderstood.

Some (untrained) developers are somewhat vaguely aware of the caching, but very often they completely ignore dependencies.

A common error is to create a template that depends on two or more assets (the first one being the c/cid, while the other is specified with extra parameters). Unfortunately, only the dependency specified by c/cid is actually recorded, so when the other asset change, the corresponding pagelet is NOT invalidated.

The net effect is a website that won't be updated when the content change (unless you invalidate all the cache).

Seven signs of a bad Fatwire implementation

I worked as a Fatwire consultant many times, and it was a very common task reviewing and assessing the quality of  the code developed by other developers (usually because the site was presenting a number of problems).

Since I saw  some mistakes many times, I decided to write down a list of the more common errors. You can check your code base against this list.

If your code shows one or more of the following signs, you are authorised to be a bit worried. Usually this means  your developers were  not too skilled on Fatwire, they misunderstood something basic, and your code may need to be fixed.

Please note: none of the following mistake is lethal but when those signs shows up, usually there are many more other, more specific, errors. Because it simply means developer never completed just the basic training before starting the work.

1. There are numeric ids in template code 

While this mistake is probably not the worse and could be fixed quickly with some manual work,  when I see this, I consider the bad sign #1 because almost certainly there is much worse in the code

It is a mistake to use numeric id in code because the whole point of a CMS is separating content from presentation. Content should be easily  changed all the time.

Since new content  have different id each time, committing to a numeric id means committing to a particular content, thus making  it impossible to change some particular content without breaking the site. Is it a shortcut taken by developers that usually did a bad job modelling the code and then they have no other ideas how to get certain content.

Furthermore, there are plenty of ways of avoiding to introduce a direct numeric id: creating relationship between assets, use template maps, even loading assets by names instead of by id.

So when you see this mistake, I suspect there are some misunderstanding of Fatwire development to a very basic level.

2.  Code is filled with direct sql queries

This is another terrible sign when I see this.

Actually, while it is is not strictly forbidden using direct queries in Fatwire, and there are a few cases where they are  actually required (for example in bulk approval), there are also plenty of libraries  wrapping direct database queries with more high level functionalities that should be used in preference.

Resulting code using queries will be longer, probably less secure (opening the door for  sql injection for example), and sometimes inefficient . Tag libraries usually do a better job of accessing the database than direct queries,

Furthermore, tag libraries do more than just querying the database: they do caching,  dependencies generation and so on. All of this  won't happen with direct database queries.

My feeling when I see code filled with SQL queries is that developer never understood how Fatwire tag libraries really works and their relationship with the content model. They are coding in the "php" way and they are not really  Fatwire developer. Probably they are just jsp or php coder in a hurry coding without a clue of the system they are using.

3.  Templates do not have a regular naming structure

Fatwire is a  content model driven CMS. The main underlying idea is the content is type.  You may  have assets types like Page, Article, News and so on. Templates act as rendering functions on each type. Furthermore,  template rendering often rely on a form of polymorphism:  you specify only the rendering function, but  you expect the same function to be available for many different types. This works if you follow regular naming rules.

In short, you should expect  for each content type a set of standard rendering functions:  for Page something like Page/Body, Page/Detail, Page/Summary; for  Article: Article/Body, Article/Detail, Article/Link. The regularity is important when you call a template specifying only the rendering functions you want, as the standard render:calltemplate tag expects  (for example a Summary, but it can be the summary of a Page or of an Article or of a News).

So I expect to see something like this

• Page/Body
• Page/Summary
• Article/Body
• Article/Summary
• /Layout
• /Link

When instead I see something like this

• /HomePageHeader
• /LeftSummaryNews
• News/HighLevelDetail
• Article/HomePageBox

I immediately suspect the rendering logic is broken (or at least it does not match best practices)

4. There are too many flex families

Flex Families are pretty rich. You can do a lot with a single flex family. Just with the types generated by the "new flex family" wizard,  with a single content and a  parent type,  you can create many content definitions (subtypes).  You can further refine your flex families adding  specific content and parent types inside a single flex family.

Your site usually just requires a single flex family, or a limited number anyway. When I see there are tons of flex families, I suspect immediately the worst.  Usually I find  there is a single content definitions for each entire flex family, and developers created a new flex family for each single content type required.

This is a bad sign, it means developers never understood something pretty basic on flex types.

Aside from duplication of attributes, one of the problems with this approach is that some relationship are allowed only within the same flex family. Having a full flex families for everything  needless limit you in creating relationships between assets.

5. You have to add each asset to a page to display it

This is another very common mistake. Many developers associate the idea of a "Page" asset with the "Web Page" concept and they end up  thinking: for each web page, I have to create a Page asset, and add assets to it. Then  they code the whole site this way.

This is just conceptually plainly wrong. There is nothing preventing you to render a specific asset as a full web page, when it is appropriate. When you have to render a specific article, and your web page only contains that article, you should  render it using as an entry point that only that asset,  not a Page that contains the asset.

Pages in Fatwire are containers of other assets, and are used mostly to build section pages and laying out the siteplan of a site. But a single asset (an article, a news, a faq) can be rendered (and normally is) as a full web page. Pages are usually the inner nodes of the site plan while non-Page assets are the leaves.

It is a completely unnecessary burden for the editorial team forcing them to use a Page to rendering a single assets: editors will have to triple efforts, because this way an extra Page asset must be required required and each asset must be be placed manually in that page. All of this is unnecessary.

6. Templates called with a lot of parameters

Templates are usually cached; to create cacheable templates, you need to limit the number of parameters, because for each combination of values parameters, a new cached element will be generated and stored.

Sometimes developer "forgot" (or just plainly ignore) about the cache, and treat template like "subroutines. Then they start passing around all the parameters they feel are required for implement every rendering, even parameters that are actually used only by inner templates.

This approach normally causes an explosion in the number of cached templates with many other nasty side effects. To limit the size of the cache sometimes many of those templates will be uncached, but this will in turno slow down the site.

Actually, the absolute minimum number of parameters (ideally, only the standard c,cid ) should be passed to a template.  Relationship between assets should be extracted by the content model.

Of course doing so  lead to multiple access to the same informations. Apparently some of them were already available before, so developers felt worth to be passed as a parameter.

But it is the job of the cache to speed up the rendering, so better to repeat the same lookup and then cache the template, that doing a lookup only once and leave the inner templates uncached because no more cacheable given the high number of parameters passed.

7. Multiple parents instead of asset relationship

This is confusion between relationship and inheritance.

Assets can be linked each other with an attribute of type "asset". Rendering the attribute will bring up  an id that can be used, while rendering, to call another asset that renders this related asset.

Unfortunately is is possible to relate assets also declaring an asset to be the parent on another asset. And it is possible to give multiple parents to an asset.

As a consequence, some people assume that the "parent-children" relationship is the way assets are related each other, so they ends up creating only parents and putting each other in relationship with the parent-children relations.

Unfortunately, parenting has a bad side effect: inheritance. Fatwire for each asset keeps in the database informations to easily locate not only his attributes, but also all the attributes of the parents, that are inherited.

Needless to say, this poses the unnecessary burden of extra informations kept, slower editing (sometimes way slower)  slower retrieving, and finally for  many relationship, accessing to related assets becomes awkward and limited.

The most frequent error in Fatwire site development

One of the more frequent mistake in Fatwire Development  that I have seen so far is overlooking the caching behaviour of render:calltemplate.

This mistake is so frequent that I take it for granted. It is always the first thing I check. I have seen it  almost in all the project I was consulted for support. The usual symptom is  that have performance problems.

Unfortunately, it can be a devastating error if discovered too late. Because calltemplate is ubiquitous, if you used it incorrectly you may have to revisit the code of your entire site, if not a complete rewrite.

In a nutshell, the behaviour of render:calltemplate is: retrieve a cached element if it is available, or execute the code to generate the html, then cache its output. In general, in 99% of the cases, calltemplate should NOT be executed: it should instead return a cached element. This behaviour has a deep impact on the way template code must be written.

If you write your code incorrectly, the  template cannot be cached. As a consequence, performances will be very bad, because retrieving content from the database is very expensive. This is the whole reason because there is a caching in place: avoiding to retrieve content from the database every time.

What render:calltemplate really does

Probably the name of the tag itself is misleading: many developers thinks that calltemplate will actually always CALL a template every time. It actually does not always happen.

Calltemplate takes all the parameters  it was called with , order them in alphabetical order and build a string like c=xxx,cid=yyy,p=zzz,site=xxx,... (note the alphabetical order to make sure that you do not have cid=yyy,c=xxx different from c=xxx,cid=yyy when you have the same xxx and yyy))

This string is used as a key for the cache, then the cache is looked for. If a cached element is found, the cached output is returned. Otherwise, the referred template is invoked and the code executed. I cannot stress more that in general executing a template can be very expensive, performance wise. Getting attributes from the database may require a lot of queries, many of them involving a join (another expensive operation if you have large tables).

To get high performances, in general you should try to get zero calls to the database in 99% of the calls.

Each template has a list of parameters that will be used as "cache criteria". When you call the template, the list of parameters is checked against this cache criteria. If you call a template with a parameter that is not listed as a cache criteria a warning in the log is generated.

Please note that instead the render:callelement has a different behaviour: it is always invoked and it is usually used to invoke standardized html generation logic.

You do not have restrictions on the arguments you pass to a callelement, because its output will not generate a separate cached element: instead its output will cached as part of the calling template. Of course if it is database intensive then it will have bad performances.

What you cannot do in a cached template

Given this behaviour, there is a number of coding practice that are forbidden

First and before all, side effects. You cannot set a variable in the environment (something like ics.SetVar("flag", "something") and use it as an implicit parameter for a called template. Something that instead you usually have to do to use a callelement to retrieve informations. Side effects are actually the only way to get return values from an utility element.

Because the template can be cached, all the parameter must be explicitly stated, otherwise you may get the wrong template. The implicit paramente will not work unless the template is uncached (and this is not good for performances).

Another mistake is using a parameter that can change too often. For example, you may pass an uniquely generated id  to a template.

Even if this id is correctly added to the cache criteria, the problem here is that a different id will create a new cached element every time the template is invoked. If you have a site with millions of users, you will end up generating a new cached element for each request!

The result here is a that the cache can became very large. I have seen sites with id passedin absolute freedom growing the cache at the rate of one thousand elements per minute!!!

This mistake will affect performance, but even worse  publication. Because publication involves invalidating the cache,  with a cache out of control, invalidating may take hours…

Understanding Fatwire Multiple Caches

When it comes discussing the Fatwire cache,  I notices very often some confusion in customer minds. I am not very surprised of this, since  Fatwire has multiple caches and their relation is pretty complex.

In this post I will try to clarify the situation, giving  an overview that explains (almost) all of the them. I am omitting here the BlobServer cache for clarity.

The structure of the available caches is depicted  in the diagram below. Read on for an explanation.

Satellite Pagelet Cache

When you visit a Fatwire website, you normally access to one of the Satellite Servers.

In the diagram there is only one Satellite, but in a normal deployment you should have many satellite servers, ideally geographically distributed in net, and the possibly located close to your browsing location, internet-wise.

Satellite Servers are the ultimate cache in place. They cache the site, splitting web pages in pagelets. A pagelet is a piece of already rendered html. It is important to understand that a pagelet is not a whole webpage, but actually only a part of a page (think to the header, a summary, a generic block).

Pagelets are  assembled  in place by Satellite to build complete web pages. Note that because pagelets are expected to be small enough to be kept in memory, assembling of a page is expected to be very fast (no database is involved,  mostly of the cache is kept in-memory except bigger files are stored on the disk). Actually Satellite spools to disk pagelets larger than a given threshold (configurable in property files).

However Satellite does not have the ability to render templates, so when a pagelet expires or is invalidated, Satellite must grab the updated pagelet from  Content Server.

Satellite cache can be inspected using a specific tool, the Inventory servlet (using the appropriate username and password), and can be flushed using the FlushServer servlet.

Content Server Pagelet Cache

ContentServer generates pagelets on request of Satellite, executing template code (either JSP or XML). It also caches the output of the rendering, for 2 reasons:

• First reason, Satellite is optional, and Content Server can run a  site without Satellite, and must do it efficiently.
• Second reason , multiple Satellites can be  deployed, so you may need to serve the same pagelets more than once. Also a Satellite can crash, or another satellite be added, so serving pagelets must be fast as well.

ContentServer cache is  the second cache in place. You can inspect the Content Server Cache looking at the SystemPageCache database table and its attachments. The servlet to clean the content server cache is CacheServer.

Please note that when you inspect the ContentServer cache you will see the pagelets generated for satellite, however cached pagelet  for Satellite are stored in memory within satellite. So empting ContentServer cache won't clean also Satellite cache. If you want to clean also Satellite cache, that you have to do it manually.

A complete reset of the front-end cache involves both all the Satellite Servers and Content Servers.

InCache Asset Cache

So far we have seen caches that store  pagelets, that are fragments of rendered  html. Those caches works with templates having cache enabled.

However it is common to have some templates that cannot be cached. Typically this happens with certain templates that  always return a different rendering (for example, searches), and caching the output pagelet can is difficult and fundamentally pointless.

The most recent addition to the family of Fatwire caches is InCache, that basically caches the  underlying "pojos" used for rendering.  You may ask what those pojos are.

When you execute template code, you perform calls like  <asset:load  name="theAsset" ...> or <assetset:setasset  name="theAssetSet" ...> to load assets. Please note that "theAsset"  or "theAssetSet" are actually Java Objects (POJO  = Plain Old Java Objects) that will be used to render the content. Loading them is expensive because a lot of database requests may be required (or at least once, that is by far the slower operation).

Enabling InCache, those pojos are cached as well. So this cache helps to speed up the rendering of uncached templates. Indeed, the vast majority of the time is spent querying the database, and reusing already queried POJO helps a lot in speeding up also uncached templates. It also helps saving memory and reducing garbage collection.

ResultSet Cache

Last but not least, there is also the old and good cache of database queries. When you query a database, you store the result in a list in memory (in Fatwire they are generally IList, that caches the output of Java ResultSets). As long as no one accesses any more to the table from where the IList was generated, running the same query will produce the same result, so it may be cached.

Result Set cache is caching results of database queries for each query executed. ResultSet are associated to tables, so  the cached results are valid until the underlying database table changes. The result set cache is invalidated table by table whenever someone write in the database table from where content was retrieved.

This cache is helpful because ultimately all the content must be extracted by the database, but is is useful also when you write custom queries. It can be tuned editing futuretense.ini and flushed using CatalogManager servlet.

The Simplest way to use Eclipse for Fatwire Development

Fatwire development has always been difficult. The recommended way of editing templates has been for a long time... ContentServerExplorer. I dislike ContentServer explorer for many reasons. For example:

1. it is a windows only app, and I use windows only in an emulator from MacOS or Linux
2. the editor embedded is so limited that notepad looks more advanced (for example from notepad you can search...)
3. the process of starting an external editor, then commit at every small change you want to test  is cumbersome

So it is natural that I has  always been looking for a replacement,  possibly using a real IDE like eclipse for development of the JSP. You know, completion, formatting, syntax checking, working syntax highlighting...

There are actually a couple of  Eclipse plugins for Fatwire Development. For a while, Fatclipse looked to be an interesting alternative. The plugin worked well and I was happy with it. Unfortunately, it is no more supported and it has not been updated to work with more recent version of Fatwire (currently it shows Fatwire 7.0.3 as the more recent supported version, and I was unable to run it in recent eclipse versions).

Then the CSDT plugins came out, but I am not happy with it. It shares the same checkout/commit philosophy of ContentServerExplorer, and is not well integrated in Eclipse. Basically it is a Java port of ContentServerExplorer, embeddable in Eclipse.

I wrote a blog post on this subject and I even developed my own alternative, FatStart.  I have now found a better way of doing development using Eclipse, so this post is basically my "adios" to FaStart, replaced  by a simpler and  better method described here.

The simpler and better way to develop with Eclipse is... not using any plugin! I discovered it is not strictly required, and you can do all your coding  in a practical and efficient way just using a recent eclipse (supporting folder linking) and a local install of Fatwire, either the JumpStartKit or your own installation using this technique.

A note of warning

The technique describe here is of course completely not official. Furthermore, in a shared environment it can be dangerous. This technique works if you do your Fatwire development in your own local instance in your machine, then you publish the changed templates in a shared enviroment.

However, if you still want to work in the old fashioned way, where multiple developers access to a shared development instance through http, your option is still ContentServer Explorer or CSDT (or even FatStart, although I do not support it anymore).

UPDATE: according Val Vakar, chief architect of CSDT, CSDT does not support shared development, although I was meaning that multiple developer can access to the same Fatwire instance and, as far as I know, it is possible, but I may be wrong.

How to directly edit the Fatwire JSP

Fatwire keeps templates as assets. So each template has some metadata, stored in the database, but the actual code is still  in a file inside a folder. This folder is located in  the Shared/elements folder. The location of the Shared folder depends on the installation. JumpStart places it under INSTALL-DIR/ContentServer/7.x.y/Shared.  In a custom install you decide where the Shared folder is.

So, if you create a typeless template named "Layout", usually you can find the actual code inside the folder Shared/elements/Typeless/Layout.jsp, while a typed template (for example Body for a Page) will be under Shared/elements/Page/Body.ksp   The actual name of the file is show in the template itself,  in the Element section. Fatwire for versioning purposes can change the name in something like Layout,0.jsp, Body,1.jsp and so on. So definitely you have to consult your template asset to know the actual file name.

So it is a pretty obvious idea trying to edit the JSP directly on the disk... However, if you do this in a default installation, you will have the surprise that... nothing happens (unless you restart the application servers). Your changes are apparently completely ignored by ContentServer.

So I thought that, because of some internal magic, direct editing of JSP is plainly not possibile... until I saw an important guy of the Fatwire team doing exactly this! Direct editing of the JSP under elements, and ContentServer actually immediately reflecting the change!

So I became a sort of detective and looked around to understand how  this is possible. An finally I found it,  actually where I expected: in a property of futuretense.ini: ft.filecheck

If you change this property to yes, you can simply edit JSP on the file system, reload your page and the result will reflect your page! Extremely agile and flexible.

So, now that I know I can actually edit JSP directly on the disk, after enabling this property all I need now is a good JSP editor.  For example eclipse. Here is how to configure Eclipse for Fatwire Editing in 5 simple steps.

Configuring Eclipse for editing templates

You need a recent version of eclipse, at least H(elios) that supports linked resources, and the Web Development Tools (so you can edit the JSP). Previous versions do not support resource linking, and  without linking, configuring the eclipse project became difficult and tricky.

Let's see how to do this step by step.

1. Create a new Dynamic Web Project

First step is to create a  new project, more precisely a Dynamic Web Project. You can create it in a workspace, it does not matter where you place it. You will actually refer to the JSP inside the elements folder through a link. So create this  project, and this is what you should see:

2. Link with the WEB-INF folder

Now, we need jar libraries and tag descriptors from Fatwire to enable JSP editing, tag library recognition, java completion and the like . Basically, all the stuff in the WEB-INF folder in the webapp part of your content server installation.

You do not need to copy them in the project (although you can do it if you like). Instead, as shown in the next image, all you need to do is to drag and drop the WEB-INF folder of the cs webapp in the WebContent folder, then LINK it.  See this image:

Please remember to select LINK  (not COPY) when eclipse asks you what to do.

3. Link with the elements folder

Now you can actually link the elements folder for direct editing. So just select the elements folder under the Shared directory and drag it into the root of the project as shown below.

Again, remember to LINK, not copy. Here you cannot copy, it would not work.

Now you can start to edit the JSP. That is all, except that eclipse will show a few errors. Next steps are here only to fix them, but if you can survive with a few errors showing up you are basically done.

4. Disable XML validation

The first error is related to XML validation. Many xml files in fatwire have still the <?XML prefix with a capital XML, and this is wrong for the Eclipse XML parser (strictly speaking, Eclipse is right, those "XML"s follow a draft xml standard, not the official one). So what you have to do is disabling the XML validation.  See the image below:

Open preferences, go to Validation and then disable XML Validator.

5. Hide a couple of JSP Directories

Some JSP present in Fatwire cannot be validated by Eclipse. Most notably, many contains a reference to the portlet jar, others have umbalanced HTML and so on. All those problems are in the system JSP that I am not generally interested in editing. So  I generally just  hide them from Eclipse eyes (and validation).

The simplest way is to go in Preferences|Resources and add an exclusion rule to hide the 2 folders "elements/OpenMarket" and "elements/fatwire". However, this system worked in Eclipse Indigo in Windows but did not work on Eclipse Helios on a Mac.

In this case all I did is to drag a void directory named fatwire and another void directory OpenMarket under elements. I created 2  new links to void directories  hiding the 2 folders creating the validation errors. .

BE CAREFUL HERE: if you drag a void directory over fatwire or OpenMarket, it once happened all the files inside were also removed! So I suggest you temporarily rename the 2 directory to another name, drag the void directory to create the hiding link and then restore them to the original name.

Final Result and Benefits

This is how  the project looks in my eclipse:

You may notice the 2 links pointing to elements and WEB-INF and the two links to hide the OpenMarket and fatwire folder. Combined with the trick described in the first section of this post, you can now can edit the JSP using the complete power of eclipse (including validation and completion) and immediately see any change reflected in Fatwire .

homework help math, chem, physics on your mobile app retain pick-up homework help inside a snap!

Get Master Cyberspace Homework Help Crafting Your individual Scholastic Newspapers. How can you suppose that completing research does not must have penning, inputting or laying the whole of the night by employing covered with ebooks? No? Now it is a fact. You will definately get homework help within the internet hands down. Consider how often that you were visualizing you should aid me with my investigation? There exists a really good flow of constructive resource literature that cannot be lent but will always grand paper writing.com/ be in the collection that you can appear to be issues up. This way you do not have to worry if your classmates beat you to the library and borrow all the books before you get there. Now all of the prayers are been told, and you will get confidential homework helper.

Pay a preparation specialized that will help do your homework duties, exams or essays please do personalized groundwork in my situation

From the moment you end up picking our organization you certainly will cherish through the internet homework help generating absolutely nothing! Finally, you will be able to take a rest from almost endless reviewing, hang out with close friends, catch up on slumber although your projects are going to be developed by our homework help composing solution. Research in the uk have established that kids which are based on their individuals and their families with groundwork will probably operate drastically more complete in academic examinations at 16 years and other than than those that do not.

Download and install a development Fatwire Instance (also on Mac)

(article updated after the post)

Fatwire Content Server 7.6 is finally available for direct download from Oracle. You can find it  on http://edelivery.oracle.com . You need to login but  you can get an account just registering for free. Once accessed the site you have a huge list of options to choose with, but Fatwire is there.

Here:

You have to choose Oracle Fusion Middleware then Generic Platform. Then you wil get a long list of Fatwire Products; there are 15 of them including Community and Mobility Server, Analytics and Gadget Server.

The good news is that they are the real products. The great news is that now ContentServer is without the license check, so you do not need to get a license from Fatwire to install it. Legally, if you are an Oracle Partner, you can use the products for Development.

But after those good news, there is a bad news. Disappointing enough, there is not the Jump Start Kit in this list. It is available from the support however.

You may already know that Jump Start  Kit is a version of Fatwire pretty easy to install, that can run in your machine without a database. Actually runs with a database but it uses the embedded embedded Hypersonic SQL Database. HSQLDB is an in-memory database, certainly not good for enough production sites.  However, because Fatwire is  heavily cached application, actually using it with HSQLDB Fatwire runs  fast and reliably enough  for development purposes.

The whole database is also stored on a single text file, and it is easy to backup it: you just need to archive that file, while using Oracle you may need to take a database dump.

It is usually pretty inconvenient  having to run in your machine a full Oracle instance for development. Even if you have a 4 Gb machine, Fatwire, Oracle and Eclipse running together in the same machine are... a bit slow (to use a moderate term). So HSQLDB is definitely my choice to get a local instance for development.

The rest of this post describes how to install the real Fatwire using HSQLDB like Jump Start Kit.

Why Install Fatwire with HSQLDB?

The interesting news is that is possible to install the real ContentServer 7.6 using HSQLDB instead of using the Jump Start Kit, although you may resort in using a small trick.

Please note that what follows is by no means an officially supported configuration.  I have used however in large projects and it works pretty well.

I have never faced any major problem using HSQLDB instead of a real database as long as you use the same version that is used in the JumpStart.

I install the real Fatwire for development mostly because there are no hot fixes available for Jump Start Kit. So if you use your local Fatwire instance for development and another Fatwire for production, you may have to update the production instance without having the possibility to update your development instance.

Indeed having development and production instances out of sync can became a major problem, since the instances must match in version number for publishing.

Another problem is the configuration installation. Sometimes I need to configure Fatwire without Engage, while it is always installed with Engage in JumpStart Kit, with no (easy) way of getting rid of it. Also there are certain demos available in the full fatwire that are not in the JumpStart Kit.

Last but not least, the layout. I really hate the layout offered by JumpStartKit. My preference is to install both the fatwire and shared folder under the tomcat directory, and the database folder under the shared folder.

This way you can distribuite the whole thing (including the tomcat and the database) just zipping the tomcat folder. And you can take a backup of the system  just zipping the shared folder, if you have the database inside the shared folder, as I usually do.

Installing Fatwire with HSQLDB

If you try to install Fatwire in your local machine using the provided installer downloaded from Oracle, r you will see that the installer offers as an installation option one of Oracle, SQL Server or DB2. So it looks like you are required to install it only with a full fledged database even, if you are installing only a development instance in your machine.

I have actually tried to install it using either Oracle XE and SQL Server Express, and it works. So you do not have to use the full Oracle instance, you can use a more lightweight version. However I have found you can actually install the full version with HSQLDB!

I have done some tests, and I was fully successful using HSQLDB 1.8.0 (the version actually used by the JumpStart) but I had some problems using version 1.8.1 . I have not tried newer version like 2.x. You will see that there is MySQL as an option but so far I was not successful, I have no idea which MySQL version is actually supported.

Here is a step by step guide how to install the full Fatwire using Tomcat and HSQLDB.

1. Download and configure a Tomcat 6.0.x from the Apache website.

2. Download HSQLDB 1.8.0 from SourceForge

3. Place hsqldb.jar  in the folder lib of the Apache Directory

4. Edit the file conf/server.xml and add this configuration (change /path/to/data to the folder where you will place the database)

<Context path="/cs" docBase="cs"
  reloadable="true"
  crossContext="true">
<Resource name="csDataSource"
  auth="Container" type="javax.sql.DataSource"
  maxActive="50" maxIdle="10" username="sa" password=""
  driverClassName="org.hsqldb.jdbcDriver"
  url="jdbc:hsqldb:/path/to/data/csDB"/>
</Context>

4. Start the installation of ContentServer download, unzipping it, running  csInstall.sh or csInstall.bat. Now answer to all the questions until you get to the  database choice pulldown. Pick whatever you want (Oracle is fine), and go on.

5. Go on with  the installation until you get  reach the point where the installer asks you to start the application server, as in the following image:

6. Now it comes the trick: click on the button Property Editor, wait for the property editor to  comes up, select Options then Change Database, and you will see the following screen showing up as in the following image:

Here you can change the database. Please note that this will only change the type of database used by Fatwire, but you have to manually configure the datasource csDataSource in the application server. That is what you did in step 4, so Fatwire should work.

7. Now you can  save the configuration file, start the application server and complete the installation. If you have done it correctly now Fatwire should be up and running using HSQLDB.

Install Fatwire on a Mac as a Development Machine

So far, the technique described  works on Windows and Linux. If you try to run the installer on a Mac however, you will  incur in  the surprise that you cannot select an application server. It looks like the configuration system does not detect a compatible application server on a OSX platform.

However, it is all just Java, Tomcat and HSQLDB works reliably on the Mac Java Virtual Machine and there is no reason because you should not run it on a Mac. It actually works.

The limitation of the installer is annoying but however it is easily overcome: just pretend on the Mac you are running on linux.

That is easy enough: edit the script csInstall.sh and add into the last line, just after the command $JAVA:

-Dos.name=Linux

That's it. This way the installer thinks you are on Linux and will let you to choose Tomcat as an application server. I have completed the installation on a Mac a number of times and it works.