Moving the blog to WebCenter Sites

Hi all, I have been silent for a while, although from access logs I see there are many visitors, and the number is actually growing.

Thank you to all the visitors,  we are not dead, yet. Actually, I has been very busy so I had not even the time to think topics to blog about.

Now I am moving the blog and all its content to Fatw... ops WebCenter Sites . I got a good working relationship with some really great guys at Oracle , business is growing fast and it is time to build a proper company web site using WCS itself and not just WordPress.

Stay tuned.

Customizable authoring website | purchase custom essay, school assignment, investigating more, dissertation, thesis and paper

There will be not enough times in a single day so that you can finish off all documents your professors count on everyone to present. Simply no undertaking how rough men and women strive to explain to their professors that the sheer number of duties is difficult, they may be always burdened with more deliver the results than they should undertake. The many authors in this most effective essays manufacturer are familiar with what rankings exceptionally. They are not just essay authors; these are generally scholastic experts and professionals that invest their precious doing the job week simply writing essays. They already have to become surprisingly good and also instantly inside their activity so are now free to produce very high credit scoring essays in a small part of time it needs a standard pupil. Cite every idea borrowed from, though we work for the complete satisfaction of every client, so we never plagiarize contenta famous creator or scholar. Aside from that, even as preparing a professional essay, the author will do all groundwork themself, follows the exact prospect directions and constructs the complete essay on your own. Composing Facility made absolutely traditional article content having to do with each papers its major profit, a whole lot task is carried out on refrain from using any similarities with reports about the same issues which really can be located in the the net.

Pay money for custom essays net qualified essay or dissertation help from authors customised dissertation publishing services of the greatest great truthful customizable essay writing specialist which in turn stones

Every time family interaction using Coming up with Expert services, you not only be given a awesome and in reality prepared essay, but develop your current growth and then get an illustration of this a cardstock to use for your intentions later on.

WCS Tutorial 1.6 – Gator and Flex Assets

While Xcelerate provide the basic functions for creating and editing asset, the more powerful content modeling features are powered by the component called Gator.

To better understand  which features it provides, I note that in the installer code it is still referred as CatalogCentre, while Xcelerate is referred as ContentCentre. So it looks like to be something good to build Catalogs. Actually it is.

Basically, Gator extends Xcelerate providing a rich and flexible Content Modeling feature called "Flex Assets". Apparently,  the original reason because Flex Assets were introduced was to support the implementation of ecommerce sites. It is not a coincidence that the first demo using Gatos is actually an eshop.  In fact, an e-commerce site usually requires lot of different products whose definition change often and unpredictably. Definitely, to support those requirements, Gator and its Flex Assets provide:

• ability to upgrade content model easily often, just publishing it
• a rich taxonomy, since products need to be organized in categories and subcategories
• an user interface to manipulate content definitions, not just content

Flex Assets differences from Basic Assets

We have already seen Basic Assets, so it is easier explaining how Flex Assets improve them.

First and before all, Basic Assets define assets with a descriptor  file, while Flex Assets define assets using other assets.  In fact, we don't talk normally of "flex assets" but of Flex Families, because Flex Assets are really a group (or family) of assets working together to reach a common goal.

Creating a new family will  indeed create 6 different types of assets. It can be at a first sight confusing, but  can be understood thinking that some of those assets are "structural" (define the type of the content) while only 2 of them defines actual content. Basically, structural assets replace the property descriptor file used in Basic Asset.

Second, Basic Assets define content once and for all, while Flex Assets define content in an incremental way. We have seen that for a Basic Asset you have to create a descriptor that will list properties. For Flex Assets you instead have to create attributes, that are assets too, then  you put together the asset using a Content Definition asset. An user interface is available to create attributes and assembling definitions.

This means mostly that while Basic Assets can be upgraded only recreating them from scratch or doing some alterations to the database schema, Flex Assets definition can be actually upgraded just publishing attributes and definitions.

Flex Asset hierarchies

But there is more. Using just Basic Assets you cannot directly create hierarchies (you can  only using some special coding). There are only some built-in hierarchies like the SitePlan. Flex Assets make hierarchies very easy to build using Parents,  that are always part of a new family definition. Furthermore, parents are configurable just like content, creating Parent Definitions.

When you create the content, you can place a content under a parent. Furthermore, a parent can be children of another parent, creating a tree. Using this parent-children relationship you can easily create complex hierarchies, that are very useful when the user needs to organize a large amount of content.

A parent has the special feature that all its  attributes are inherited by  its  children content. This feature is largely used to create custom hierarchies. Actually given the simplicity, is a bit unusual to find a flex family without parents, since they  are very easy to use.

Flex Families Components

So, let's recap what we have said so far. When you create a new Flex Family, you go into the Admin panel in the user interface and   see the following screen:

The Flex Family Maker  creates a number of new different types. Let's explain their meaning and use.

First, you  define a new Attribute type, Content_A in the picture. Attributes are  fields of the content,  the building blocks.

Then, you will have to create definitions to put attributes together. So basically, to define an Article with a title, an author and a body, you  have to create 3 attributes corresponding to the fields, then one Content Definition (a Content_CD asset for the family in the picture) named Article assembling the attributes you have declared. You can create different content definitions, each of them will define a different Content type.

Now finally you can create content, this means you will create an actual Flex Asset of type Content, and you will then associate one content definition, like the Article Content_CD you may have created in the previous step.

You can also create assets useful to organize content in hierarchies. This works in the same way as the content. First you create a parent definition, assembling attributes, then you can use the parent definitions to create parents. The additional step is that you can now associate content  to parent to get a hierarchy. The whole hierarchy can then be displayed in the WCS user interface. See below an example of such a hierarchy:

WCS Tutorial 1.5, AssetMaker and Basic Assets

Basic Assets

Xcelerate provides some built-in asset (an absolute requirement to build a site). However, since WCS  has a rich and flexible type system, you can define your own assets. Well, you actually should, unless you stick using sample assets, but you would lose a good deal of flexibility.

There is a lot to say about all the available possibilities to define your assets. For now, we  limit the exploration  to the features  provided by Xcelerate, namely the Basic Assets. Actually, there is a  more powerful and interesting possibility, Flex Assets, but this feature is part of Gator, that will be  described later. Furthermore,  Basic Assets are still useful although I do not recommend building a site (unless very simple and unlikely to evolve) solely on Basic Asset.

Define a new Basic Asset with AssetMaker

Let's jump start on  Basic Asset  showing an example how you can define it.

Although a bit technical as a approach (this is one of Basic Assets's drawback)  you have to describe it creating an XML file.

A very simple example of a Basic Asset descriptor looks like this:

<ASSET NAME="Simple" DESCRIPTION="Simple"  PROCESSOR="5.0"
       DEFDIR="c:\Fatwire\Shared\Storage\Simple">
  <PROPERTIES>
    <PROPERTY NAME="value" DESCRIPTION="Value">
        <STORAGE TYPE="VARCHAR" LENGTH="80"/>
        <INPUTFORM TYPE="TEXT" WIDTH="50"
          MAXLENGTH="80" REQUIRED="NO" DEFAULT="" MULTIPLE="NO"/>
    </PROPERTY>
  </PROPERTIES>
</ASSET>

What a basic asset provide

It is a simple asset, maybe the simplest possible, but this example  demonstrates what an Asset can provide.

First , as asset, like a database table, is essentially a sequence of fields, here called properties. As you can see here, each property has a storage type, so basically properties are translated in  fields of a database table.

But you can also note an important difference from database table: for each field, it is declared  how the field will be edited. In this example, you simply use a simple input text form, but with some constraints:

• width 50 characters,
• up to a maximum of 80,
• the property is not required,
• default value  is a void string.

It is however also pretty simple declare a property of type blob, that  will generate a form with a file upload. The file, once uploaded, will be stored in a folder. As you may remember we just discussed that tables may have attachments. Here we define the folder where attachments will be stored, and  thus this information is mandatory.

Basically we have seen so far how an Asset extends the concept of database table providing informations for forms editing and attachments. Actually there is more, there are many pre-defined asset fields generating various for but we will investingate on those features later. For now, just understand the concept.

Please note that Basic Assets  have however some limitation.  Most notably:

• they require coding to be defined
• they are a bit inflexible so you cannot add fields later unless you manually alter database tables
• they have limited relationship (actually provided by a feature called Association)

In the following of this tutorial we will see how those limitations has been overcome by  Flex Assets, at the price of increased complexity and lower performances (however compensated by the widespread use of caching in WCS).

WCS Tutorial 1.4, understanding Xcelerate

So far we have introduced only the basic concepts of the ContentServer layer. Basically it is the intepreter of the underlying  web programming language of WCS.But WCS is an application, and his value is mostly there. Se we  start now examining applications.

I prefer to distinguish the different underlying modules and use their internal name, because understanding which module we are talking about make easier understanding how the various modules interact. For example we will see that a Role cannot impact on ACL because the ACL belongs to the underlying layer.

Now, let's examine the first applicative layer built in ContentServer, Xcelerate.

Xcelerate

Xcelerate is the internal original name of the CMS module (at some point in the history called also CS-Direct), and it is still available today,  and is better known as  the Advanced Interface. You can still see the Xcelerate name when you log directly into the WCS advanced interface using the  URL

http://www.yoursite.com/cs/Xcelerate/LoginPage.html

Also you can see many elements named Xcelerate when you look at the ElementCatalog table.

In ContentServer we have only a concept of code. We have seen that code is actually stored as an attachment to a database table. I remember that a single piece of code, stored in a file and attached to a record in the ElementCatalog table is called Element. Basically, managing elements is the main job of ContentServer.

Xcelerate introduces a new concept, the Asset. Creating assets, managing them and providing a rich user interface for this purpose is instead the main job of Xcelerate.

What is an asset? In its simplest incarnation, an Asset can be thought as a single record in a database table. However it is not just this.  Asset can be of different types, and each asset type has their own methods for editing. So basically for each asset there are associated  forms to create and modify it.

It is important to understand that an asset is not limited to a single database table: it can actually store references to other tables. For example, the asset Template, since it allows to edit an element, is stored mainly in the Template table but it references (and allows editing) also record stored in the ElementCatalog and SiteCatalog tables. In a sense, Xcelerate provides also a user inferface for ContentServer through some specific assets.

System Assets

WCS comes bundled with a number of predefined assets. Those assets are used to implement  some standard WCS features.

As an example, let's consider the asset Page. This asset is used to build a the hierarchy of web pages in  our web sites, and there is a standard feature, called the site plan, that renders this hierarchy. We will discuss of Pages and SitePlan in greater detail  later. So far I used it only as an example of system asset. But before we move on, an important note:

A Page is NOT used to represent a single WebPage. I mean, it is wrong to assume (as many does) that you have to create a Page to render each asset as a Web Page. Page are actually used to model Sections in your site, not the complete site.

It is also immediately worth mentioning that ElementCatalog and SiteCatalog tables have a counterpart as an assets.

Basically a single entry in the ElementCatalog table can be created creating an asset CSElement, while an entry in the SiteCatalog table can be created with an asset SiteEntry. Please note that each asset has also its own table (and sometimes other additional side tables). So CSElement and SiteEntry are stored each each in 2 different tables (CSElement/ELementCatalog and SiteEntry/SiteCatalog).

We already mentioned the Template asset, that is also the more widely used asset when you build websites. This asset actually creates both an entry in the Template table but also it creates an entry in the ElementCatalog, and even one or more entries in the SiteCatalog table. So basically a template is stored at least in 3 tables: Template/ElementCatalog/SiteCatalog.

We mentioned also the Page asset, and while it is stored mainly in the table Page, but the hierarchy on pages is stored in a separate table called SitePlanTree.

So far so good providing examples  that clarify there is not an one-to-one relationship between tables and assets.

Next step will be to examine custom asset defined in Xcelerate, the so called Basic Assets.

WCS Tutorial 1.3, Content Server request processing

Before going into the details of the applications, I will explain further how Content Server processes  code, mostly to show how it differs from other web programming engine like PHP or plain JSP.

Invoking ContentServer

You invoke ContentServer with the URL

http://www.yoursite.com/cs/ContentServer

Here http://www.yousite.com/cs/ can change according your domain name and where you have installed it, but the ContentServer servlet must be always invoked, and you have also to specify some parameters. The most important parameter is pagename.

As a general rule, you can assume ContentServer?pagename=Element invokes some code, written either in CSXML or in JSP. The specific code may require more parameters to process but the parameter pagename is the one you require to invoke the code.

But before going into more details, you have to know how the code is stored inside WCS.

First, let's introduce some terminology: within WCS code is called "Element". An element is either a pieces of JSP os CSXML code. Code is stored in a file inside the file system, but cannot be accessed directly pointing to it in the filesystem, as you do in PHP and JSP.

Indeed,  there are some "metadata" associated to each element, and those metadata are stored in the database. So basically you have to read the database, and the database will tell you how to process the code.

There are 2 database tables involved : ElementCatalog e SiteCatalog. But before explaining those tables, I need to digress explaining how files in the filesystem are related to database tables.

A digression: tables with attachments

A database table for ContentServer is nothing really special, it is similar to any other table except there are a few conventions to be followed.

The first one is that every table managed by Content Server has at least the following 3 fields: "id", "name", and "description", and must be know to content server by registering it in the SystemInfo table (a special table used to index all the other tables in the system). ContentServer consistently create records with a name, assign then an id that is uniquely generated, require a name that is mandatory and offer the opportunity to store a description of the record.

Another important convention is that a table can have files  attached. But instead of storing them as blob (whose usage is pretty inconsistent between  different databases) files are actually stored in the file system, and only a pointer to the file is stored in the database table. The general convention is: when a field starts with "url" (or is just url) then its content is actually the relative path on the filesystem where is stored the file.

You may ask: relative to what? Well, as said the special table SystemInfo  stores some informations for each table. In our case, it stores the base path for files attached to each table. So basically it works this way: when you need to attach a file to a database table, you need  a field with a name starting with "url", then

1. define in the SystemInfo table a folder where files for that table will be stored
2. store in the url field the relative path name for the file
3. store the actual file in the file system, using as a file name the top level folder defined in step 1, plus  the value stored in the field as in step 3

 The ElementCatalog and the SiteCatalog tables

So you now may wonder: what has this digression has to do with the ContentServer code processing? It is simple. The code to be executed is stored in a file attached to the table ElementCatalog as just described.

You can refer to each element with its name, but the name is used to locate a record in the ElementCatalog table. ElementCatalog stores informations like last modification time, and other stuff. Then, the actual file containing the code, is an attachment to the ElementCatalog table.

Please note that using the ElementCatalog, you can invoke that code from another element using internal calls like the ics:callelement call;  but you cannot invoke the element from the servlet url with just its name in the ElementCatalog.   This is both for protection and for caching.

But it is of course still possible invoking code from the ContentServer servlet, as I explained before, using the ContentServer?pagename=Element. Hovewer, the Element heade does not refer to an entry in the ElementCatalog table, but instead to an entry in the SiteCatalog table. In the SiteCatalog table there is a field linking to the actual entry in the ElementCatalog table, which in turn points to the actual code.

SiteCatalog actually has an additional purpose: caching elements. When you invoke something from the URL, the SiteCatalog is looked up but it does not necessarily call the underlying Element it points if it has already a cached copy available. Also SiteCatalog allows  to create different entries for the same element, adding parameters for each of them, and eventually caching the output of the same element in a different ways.

How a request is actually processed

Let's recap the whole thing. This is how a content server request is actually processed:

1. the user follows a link with an url containing ContentServer?pagename=Element,  eventually with other parameters
2. the whole combination  of parameters is looked into the cache, and a suitable entry is available and (and is not expired), it is returned as a result, and the processing ends here.
3. if the requested Element has not a valid cache entry, it is looked into the SiteCatalog table and the field rootelement is used to locate the actual element in the ElementCatalog table
4. the ElementCatalog table is used in turn to locate the actual code;  field url points the the code,  concatenating its value with the top folder for this table (as specified in the SystemInfo table)
5. Now the actual code is located on disk and it is exectued; in general an element does not produce a whole web page but only a small snippet. The code can in turn invoke other elements.
6. Once the element has completed its work, the processed value is stored in the cache using informations from the SiteCatalog table
7. Finally the result of the call is returned to the end user.

Please note again this is not yet the whole story. An url assembler can be invoked before ContentServer, actually hiding the pagename=Element parameter, an apache server can be in front of ContentServer, and a remote Satellite server can be used in front of the Apache+ContentServer combo to add another layer of caching. But I will talk about  this later.

WCS tutorial, 1.2 – Understanding Content Server

We have seen that WCS is actually a layered system. Now it is time to go into the details of each layer to see which features they provide.

Content Server

The core of WCS is the Content Server layer. Although until recently the whole product has been called "Fatwire Content Server", actually  Content Server  is just the first layer. You actually call Content Server when you invoke the URL "/cs/ContentServer" (or "/servlet/ContentServer" or whatever your context path is)

ContentServer is basically an interpreter of an XML-based programming language developed before the year 2000 (presumably around 1995). It looks like the original developer wanted to implement a sort of custom ColdFusion-like  but extensible programming language. I am familiar with the idea since at the time I built something very similar.

Content Server CSXML

At the time of the initial development of WCS, the new XML standard was very young, and its purpose was a bit unclear. The obvious idea was to use XML as a programming language, and using the custom tags  programming constructs. I think so because I thought exactly the same thing.

Today I would say that it was not such a good idea mostly because XML is not really suitable to be a good programming language. I notice however that other CMS (for example, OpenCMS) works in the same way, and have a custom language based on XML.

The Content Server XML is not  generic XML, but a sort of custom programming language that I will call it, not having a better name, CSXML. Later WCS added to the CSXML  with something more standard, and more general: JSP, allowing programmers to use the more familiar Java programming language instead of a proprietary and somewhat limited programming language.

One funny thing in Content Server is that it  still uses an XML parser, written in Java but developed  by Microsoft! If you look to the jars in the WCS installation, you can still find the MSXML.jar. There was a time when Microsoft was Java friendly (they licensed Java  and  developed a version of Java for Windows for a while). Then they moved on... and C# is another story.

When XML came out, Microsoft  developed one of the first XML parsers,  an open source one, and it is the parser that still today ContentServer uses to parse his CSXML.  Please note that the MSXML parser is not even standard compliant since it was developed before there was actually a standard for XML, and it has some oddities. It is not validating, and it has tag names  case insensitive , but  attributes are case sensitive...

CSXML is extensible, in the sense that you can develop custom tag libraries and invoke a tag. It is widely used  in WCS since large part of the Xcelerate and Gator layers are developed in CSXML. You also need to use  CSXML when you want to customize the interface.

Actually not everything in Content Server is implemented in CSXML. CSXML is a sort of scripting language to implement the user interface but all the underlying logic (especially the database access logic)  is actually implemented in Java, packaged in jars and called through tag libraries. There are many tag libraries and only a  fraction of them is actually documented for site development purposes.

Content Server JSP

CSXML is not the only way to develop for Content Server. There is also another, more standard, programming language available: I mean  plain simple (and standard) JSP. So basically you have the choice of using CSXML to code your site and customizations, or use standard JSP (that of course allows you also to code the logic in pure and simple Java).

However, ContentServer is not just a plain JSP interpreter. It provides a lot of other services, that in CSXML are accessible through custom tags. The same is true also for JSP. The smart idea is that every tag defined for XML  is available as a custom tag library for the JSP, with the same name and the same attributes.

So for example you can load an asset in CSXML using

<ASSET.LOAD TYPE="..." OBJECTID="..."/>,

bug you can do the same in a JSP using

<asset:load type="..." objectid="..."/>

Of course it is not just that in JSP you can use asset:load while in CSXML you use ASSET.LOAD. There are many other differences, in JSP you can use scriptlets, expressions like <%= ... %> and  <% ... %>,  while in CSXML you cannot, and you have to use a string replacement mechanism provided by CSXML for variables. For simpler things you can use CSXML but it becames easily too limiting. I am not going to go into the details however, since I consider CSXML leagacy and I will focus mostly on JSP.

WCS tutorial 1.1 – under the cover

I am starting with this post a series that aims to be a  tutorial on  WebCenter Site (the new name of Fatwire Content Server).

In my plans, once completed you can use it as a gentle introduction to WCS, useful to be read before approaching the long (and complex) documentation. For this reason, I will focus more on the concepts and less on the details, leaving to the official documentation the task to delve into the specifics of every subject.

In this first post, I am just introducing some fundamental concepts of WCS.

WCS layers

It is not immediately obvious for anyone who have not seen the evolution of the product,  that it is actually built of some different layers. This fact was more evident some time ago, when they were installed separately. Since now you install everything out of a single installer  you may need some explanation to see those layers.

Knowing those layers is actually useful to better understand how WCS works. I am referring to those layers with their original name, because when you develop for WCS you will see them in the code:  internally those names are still used.

Content Server

The first layers is Content Server in the proper sense.  Although until recently the official name of the whole content management product was "Fatwire Content Server", in the original naming Content Server is only the first layer. Content Server is basically an XML based web programming language, similar (as a concept - not in the specific details) to ColdFusion, a web programming language that was "hot" at the time of the initial development of the product (around 1995).

Content Server was further extended adding to the XML based programming language (that is still there) a more powerful and more standard JSP based programming language. Both the XML and the JSP share the same underlying libraries, so everything that can be done in XML can be also implemented in JSP.

ContentServer however is mostly  just an execution environment, with some features like security and caching, but it has no concept of assets, nor a proper user interface (except a very limited one used  mostly to configure security). You can think to it like a sort of  JSP engine, more powerful than just the JSP engine you can find in a standard application server, but definitely not an application.

It is the underlying engine used by the other components.

Xcelerate

When you use WCS, you normally expect to log into it and manage some content. Built on top of ContentServer, there is the Xcelerate application, that has a web user interface. Xcelerate is different from ContentServer since the former is built with the latter. Xcelerate also features  a rich user interface, allowing to create and edit content.

Xcelerate implements the more important concepts of WCS: the Asset. There are some predefined assets like the Page and the Template, and more assets can be created. Xcelerate actually implements only the concept of Basic Asset, giving you the ability to create more basic asset definition  using the Asset Maker. In the original design, Xcelerate is an engine good for developing even complex web sites but with having a content model that is pretty stable and not expected to be changed often.

Gator

A further extension of Xcelerate is Gator, that basically implements the concept of Flex Asset. Flex Asset were originally designed to easily implement e-commerce web sites. A typical problem of e-commerce is that the content model can be very complex and changed often, sometimes daily, so the Basic Assets were not enough flexible for this purpose.

Flex Assets fulfill the flexibility this requirement, providing the ability to change the content model easily,  keeping the existing content safe, and allowing an easy update of the site, as simple as the publishing.

Publishing, normally used to just update the content,  cannot be used to update the content model when using only basic assets. But you can update the content model using Flex Assets, and then just publish them to update the site.

Gator also implements the ability to customize the administrative user interface introducing also the concept of Attribute and Attribute Editor.

Engage

Another layer is Engage (once called "Marketing Studio") that further extends the feature set of the system, providing the ability to store attributes of the user (Visitor Attributes), build rules based on them (Segments) and generate content dynamically (using the so-called Recommendations and Promotion).

Everything else

The analysis is not actually complete: there are other components in the full system; they are  built however on the same foundation but integrated, so I will stop the analysis here. I reserve to provide more details about the other components in a future post.

Discussing CSDT and FatStart with the architect

Val Vakar (CSDT Architect/Lead Engineer) was so kind to comment my "review" (let's call it a review - it is not) of CSDT. He raised a number of interesting point that I am going to discuss here.

I am going to compare actually CSDT with my own FatStart/ElementDeployer. Of course I am biased here since FatStart is my brainchild. However, I would be happy to drop it and use CSDT instead if it was addressing all my development concerns. Since it does not, yet, I am going to keep it and instead I ask Val to improve CSDT to the point I can drop FatStart.

I have been looking for a valid Fatwire development environment for ages, and I do not count CSE as a development environment! At the moment I am still using  the development environment  I built by myself.

Response to Val comment

Let's see what Val says:

Ciao Fatcoders!

Pleased to meet you, Val.

Just a couple of comments on your CSDT review:
1. You’re right that the fundamental difference between CSDT and Fatclipse is that CSDT works locally whereas Fatclipse works with a central server. This was a deliberate decision to bring FatWire development in line with normal J2EE practices where there’s distinct separation between development and deployment so that developers never deploy code directly from their system (even to test environments). For example, consider deploying a JSP to a remote WebLogic or Tomcat instance (and no folder sharing) – see what I mean? This approach is necessary to be able to maintain structure during concurrent development – more than one developer in a team, possibly editing the same JSP at the same time.

Well, however to test a JSP you still have to publish it back to the  origin  server, as far as I know.

Does CSDT provide protection when 2 developers upload the same JSP? Does CSDT allow for a merge of concurrent modifications? If it does not,  we really  need it.

My understanding is that if one developer check out a jsp, and another developer checkout the same jsp from the same server, when they publish their changes they can still overwrite their work each other.

Am I wrong here?

It would be very useful if I could publish my jsp on a separate server (a local jumpstart for example) for testing. But in current incarnation of CSDT, I cannot, since it is limited to one server.

To address those development issues, using my  home grown Element Deployer  I can assign a jumpstart to each developer. Each developer checkout the jsp from the repository (not from a centralized fatwire), merge his changes the codebase, using standard version control techniques, and then deploy all the  code in his local jumpstart for testing.

It is easy. It simple. It works. And it does what everyone else in the J2EE world takes for granted: you work in your own  local server for testing.

CSDT instead assumes you have only one, centralized server, from where you  get and where you put your code. Not very standard J2ee in my view (although it is a standard Fatwire CS practice, unfortunately)

2. As to your question “(you wonder: why???)”, the answer is simple: CSDT is primarily an export/import tool; the Eclipse part is just a small part of it, and is not even required. Furthermore, CSDT is designed to be portable between IDE’s.

Fine, but here you are saying "CSDT is not really integrated in Eclipse, is is just hosted in it".

This means you cannot use your IDE version control tools, defeating the whole point of using the IDE.  Furthermore the directory layout where CSDT stores his content is "opaque" and you have to do reverse engineering to discover where is it. Also file names are generated by CSDT.

I do not feel  confident I can safely version controls files that I do not manage (it is the tool who decide where things go and their names, not me).

Using my basic "ElementDeployer" I just create files in Eclipse, that can be edited as normal JSP files, I can version control them with the IDE.

I really do not see the point of treating Fatwire JSP as special. They are not, and they can be edited as normal JSP (provided you tell eclipse where jar and tld are, and this is just a matter of creating a link).

In this matter, the old FatClipse was doing a better job, and I just using his technique: edit Fatwire JSP as normal JSP (just adding some jars and tlds to eclipse via a link).

3. Finally, regarding seeing changes immediately upon save – CSDT actually does that in your local environment (you can also use the embedded browser in eclipse refreshed using Ctrl+R, which some people find extremely convenient).

I think you are missing the point here: what I mean is that with my ElementDeployer I just save a jsp, and the result is immediately DEPLOYED on ContentServer (but I am assuming it is deployed in my local jump start, please note, not a shared CS)

Instead, deploying with CSDT is a long sequence of click. When you are working on fixing templates, you need to deploy the code very often .  With CSDT I have to deploy the code, with ElementDeployer I have not. It is immediately deployed on the server.

I am talking of using my local jumpstart server, again. Of course, I agree that using ElementDeployer with a shared server is very dangerous.

Of course, this is within the J2EE development guidelines of separating development from deployment, so your target system will not be updated until you deploy. People use CI frameworks like Hudson for that sort of work, btw.

If you work in a small team it is understandable that you would like more direct methods of working with the test server. However, hopefully we can agree that after bringing in a few more developers things are bound to become messy.

First, I work with a team of 3, and we have to share code and merge our changes all the time. 3 or 30 do not change too much in this respect: you have to merge your changes with others. I do concurrent modifications.

For this reason, I am saying that you have to work on your local jump start, then commit your code to a code repository. You have to rebuild your  QA server with code taken from the repository. Here you can use Jenkins for the task (ex-Hudson).

Anyway, I hope this didn’t sound like I was preaching or anything. I very much appreciate it when people bring up issues with CSDT. This is what helps us make things better in the future.

I am happy you are explaining your point of view. Honestly I am not sure I understood everything of CSDT and  I may  using it incorrectly.

I am writing here my opinions. I will happily publish your answers and correct my misunderstanding.

However...

Why I still prefer FastStart and ElementDeployer

Shameless plug! So far, I still prefer working with ElementDeployer and my FatStart.

Here is why.

You just need a single java class I call the ElementDeployer,  and a bunch of html/javascript files. All of this is the FatStart project. Benefits:

• you get instantaneous gratification (otherwise called rapid application development)
• you can use  your IDE with its version control system
• you have a solution for concurrent modification problems
• you can use a standard Eclipse (or Netbeans of Intellij) since it does not require any  plugin.
• you can develop also with older CS versions while CSDT requires 7.6 and the WEM installed (that is not a light requirement).

Of course there are  a number of assumptions.

The  more important  is that you Fatwire code is stored in a shared code repository (I use git) but each developer has his own local  jump start.

Every developer need to build a complete copy of the environment, including content model and sample content in his jumpstart.

Well,  you do this  using FatStart, that is basically a Fatwire Project deployer.

So: you create your content model with FatStart, edit it with element deployer, distribute to others using a version control system. A QA system is built from sources and scripts, and from there everything is published to preproduction and/or production.

A new FatGoodie: FatProject

Yesterday I had to create quickly a new Fatwire Project. This time, since I have CS 7.6 I decided to try CSDT (you know, the new Eclipse Plugin for eclipse development). But...

What is wrong with CSDT

Well, the experience with CSDT did not live  up to my expectation. Don't get me wrong: I think that CSDT is basically fine. However, it is not what I was looking for.

Here a few  things I don't like.

First:  it stores content in his own directory, that is NOT the Eclipse project directory. So I cannot really version control it, unless I create a separate repository and use the directory where CSDT stores files. While it is doable, it is a bit annoying (you wonder: why???)

Second annoyance: I configure it once using my local jump start. Now I am unable to change settings.  I want to use indeed a different Content Server (accessible through a VPN). With CSDT once you have configured it, it looks like you cannot change that configuration anymore, unless you create a new workspace. Not sure why, but definitely annoying.

Last thing, I have to manually publish changes once in a while. While definitely not a big deal, it is annoying nonetheless, especially if I have the habit to see immediately  the changes once I hit save in eclipse.

FatProject was born

So, after this frustation I decided to come back to my FatStart. Well, actually I just picked the ElementDeployer, since I do not need the complete packaging power of FatStart. I only was looking for the ability  to use eclipse to edit and  deploying elements in the quickest possible way. Basically an eclipse replacement for ContentServer Explorer, more efficient that CSDT for this basic task (actually CSDT performs other tasks but I simply don't need them).

All I had to do is to create an eclipse project, copy in it the ElementDeployer (part of FatStart) and configure a link to the cs/WEB-INF directory. I also added a launcher script to perform deployments manually.

So basically I created a bare-bone eclipse project supporting ContentServer and  able to edit jsp (with completion!) and deploy code changes when I save it.

I thought that this personal stuff can be useful for others, so I collected the eclipse project and I released it in my FatGoodies collections as "fatproject":

How to use FatProject

Checkout the code from here:

https://github.com/sciabarra/FatGoodies/tree/master/fatproject

Then import the project  in Eclipse. If you  have CSDT already configured, that is all; otherwise you will have to set up the eclipse variable "CS_CONTEXTDIR" to point to your local jumpstart "cs" directory.

Now, create your elements and templates. You have to follow a couple of conventions for naming them (see the doc). Then  you can just launch the ElementDeployer class.

It will look for an ElementDeployer.prp file to read its settings then it will  publish jsp (with extension .jspf please) to the Content Server you configured.

Then keep it running. Every time you change a file it is immediataly redeployed.

This is basically all I need to code with Fatwire if I don't have to distribute a complete package (for which FatStart is better suited).

Using this simple FatProject I am in a productive loop: I edit the content model in Fatwire and I save it, then I edit the code in Eclipse and I save it, and I am done: just reloading the page (well, don't forget to disable or clean the cache, anyway)  I can see the results of my changes.

And I am happy!

(It took more time to write this blog post than to build fatproject actually)