Posts Tagged ‘studio-char-limit’

Cool Tools 19: Frevvo Live Forms (with WCI Integration!)

Friday, May 27th, 2011

We’ve spent some time recently talking about AquaLogic Studio Server, and even got a tip from our buddy Geoff Garcia about the date Oracle officially stopped supporting it (November 2010).

So now what? You still have requirements to easily build forms and workflows and reports, but aren’t planning on a full move to another platform in the short term. Well, at a recent project where we’ve deployed Atlassian’s Confluence (also integrated with WCI), we came across this great form-builder plugin called Frevvo Live Forms.

In a word, it’s awesome – check out this quick demo (more videos here):

That got us thinking: what about using Frevvo as a replacement for Studio? We could develop the integration so that forms could be added as portlets and administered just like Studio. It’d do everything Studio can (integrate with portal security settings, custom-define forms and fields), have great new features (new data types, drag-and-drop form building, workflows), and, well, it wouldn’t suck like Studio.

So, that’s exactly what we did:

Interested in how to dump Studio and move on to a more powerful form-builder with workflows and much cooler reports? Contact us.

Increasing the Character Limit for ALI Studio in SQL Server

Sunday, May 22nd, 2011

By now you’re aware of our stated problem – we need to increase the size of text fields in Aqualogic Studio. We’ve already found the file used for the JavaScript, and used a new Cool Tool (HxD) to assist in the recompile, but there’s still a problem: when Studio creates new forms, it also creates a separate table in MS SQL Server. And the size of text fields in those tables that already exist is still 1,000. So if we just update the Javascript, our existing forms aren’t going to have the proper error checking, because our JavaScript is preventing field sizes of, say, 10,000 characters, but at the database layer, the size of those fields is still 1,000 characters. Even worse, if you try to increase the size of the table in the code to >4,000 characters, SQL Server will reject it because the regular nvarchar data type doesn’t go over that limit:

2011-04-21 14:54:54,819 ERROR [rocessor25] AppDesignerHandler: Error processing wizard form post
Error creating new user database ‘Survey Database’.
– [XNRC39]The size (10000) given to the column ‘test_10000’ exceeds the maximum allowed for any data type (8000).
at com.plumtree. studio.model.data. access.TableDAOSQLServer.create (TableDAOSQLServer.java:220)
at com.plumtree. studio.model.app. Table._create (Table.java:585)
at com.plumtree. studio.model.app. Table.save (Table.java:618)

So, we have two problems: first, we need to tell Studio to create these fields with a type of NVARCHAR(MAX) rather than NVARCHAR(10000), and second, we need to update all existing tables.

The first problems is pretty straightforward – we just need to update the TableDAOSQLServer.java file (or, if you’re on Oracle, TableDAOOracle.java). Change:

      sqlBuffer.append(this.mUserColumnType).append("(").append(this.mUserColumnWidth).append(") ");

…to:

      sqlBuffer.append(this.mUserColumnType).append("(MAX) ");

… and recompile as mentioned in the last post.

The second problem requires some SQL Server voodoo – we need to write a SQL Script that generates a SQL Script. So, if you run this script as your studiodbuser:

SELECT 'ALTER TABLE ' +  syo.name 
    + ' ALTER COLUMN ' + syc.name + ' NVARCHAR(MAX);'
   FROM sysobjects syo
   JOIN syscolumns syc ON
     syc.id = syo.id
   JOIN systypes syt ON
     syt.xtype = syc.xtype
   WHERE 
     syt.name = 'nvarchar' 
    and syo.xtype='U'

… it will produce a SQL Script that looks like this:

ALTER TABLE PTU_SHPR2_Progress_Revi ALTER COLUMN Additional_Comments NVARCHAR(MAX);
ALTER TABLE PTU_SHPR2_Progress_Revi ALTER COLUMN U__Is_the_work_proceeding_i NVARCHAR(MAX);
ALTER TABLE PTU_SHPR2_Progress_Revi ALTER COLUMN U__Is_progress_towards_the_ NVARCHAR(MAX);

So basically, you’re using s script to find all the existing text fields, and creating a new one to actually increase the size limits on those fields.

Cool? Cool.

Cool Tools 18: HxD Hex Editor

Thursday, May 19th, 2011

Continuing our journey on increasing ALI Studio’s character limit, we’ve now identified the code that needs to change – it’s in com.plumtree. studio.model. data.access.TableDAO.java.

The problem is, Studio is ancient, so while we can easily update the following code:

  protected int mUserColumnWidth = 1000;
  protected int mUserColumnWidthChars = 1000;

… we can’t just recompile the file using the latest JDK without expecting problems.

So, we need to figure out what Java version was originally used to compile this file. To do this, we need today’s Cool Tool: HxD Hex Editor. Why? Because all Java .class files have the same set of bytes at the beginning identifying them as Java files, along with the JDK version used to compile.

HxD allows us to view the actual bytes, and and it does it well. Opening the TableDAO.class file in HxD, we see:

Bytes 6 and 7 are “00 2E”, which represent JDK 1.2.

Once we’ve made our changes and have the correct JDK downloaded, we rebuild the file, making sure to include the proper .jars in the CLASSPATH:

set CLASSPATH= %CLASSPATH%; C:\code\studio\ WEB-INF\lib\log4j-1.2.8.jar
set CLASSPATH= %CLASSPATH%; C:\code\studio\ WEB-INF\lib\jakartaRegexp1dot2.jar

C:\jdk1.2.2\bin\javac -classpath %CLASSPATH% com\plumtree\ studio\model\ data\access\ TableDAO.java

Take the TableDAO.class file, jam it back into your studio.war file, and you’re good to go – assuming you haven’t increased that value over 4,000 characters! There’s still one more glitch in this journey

Increase Plumtree Studio Character Limit

Monday, May 16th, 2011

We don’t write much about Aqualogic Interaction Studio ’round these here parts anymore. That’s because Studio has long since been end-of-life’d (by BEA, even before the Oracle acquisition!). But, that doesn’t mean it isn’t alive and gasping its last breath in many of your portal sites. Sure, it’s an over-the-hill product but it does serve a functional need: the ability to easily create forms, polls, and other data entry forms.

So, it’s with reluctant enthusiasm that I start the first of a three-part series on “How to increase the 1,000 character limit in Plumtree Studio”. Even if you don’t actually use Studio, hopefully you’ll find the journey interesting and informative for your other portal diagnostic needs. I’ll walk you through the process of identifying the code here, recompiling and reintegrating in Part dos, then some SQL Server diagnostics in Part tres.

The problem, as recently presented by a client, was that Studio has a 1,000 character limit on text fields. If an end user tries to type more than 1,000 characters, they get this lovely message:

But, we needed to increase that value. While it would be really nice if there was just some configuration file somewhere, sadly, the 1,000 character limit is hard-coded. So we first need to find the file that’s producing this alert. (more…)