TaskHeap

Tasks that are specific to just the TaskHeap application. These may help demonstrate what's possible with SAND apps, but don't automatically apply to other applications.

TOC

1.1.1 Get the ExternalPlan refresh working (pending 16 hrs) id: 1317

As an http client, assume that the URL for the ExternalPlan points to the report output area where that plan can be found. Read the remaining hours off that report if asked to recalc.

TOC

1.1.2 Email WBS (pending 16 hrs) id: 1264

Add a button to generate the WBS report and then email it to yourself, without actually exporting it. That's useful for generating various possible planning scenarios for consideration, and it serves as an example for using email in a SAND app.

[Eric Parker] generalized email utility

If it turns out to be possible to factor a generalized email utility into sand/apps/basics then we should do that. Note that apps/basics can only depend on J2SE.
[Eric Parker] 14aug05 forgotPassword example

At this point the forgotPassword processing serves as an example of using email within a SAND app, so it comes down to whether emailing the heap to yourself is a good thing to do. In practice it's better to email a link to the static page, but since we already have a chunk of code in here we may as well finish this. Do the easiest thing that works. Assume html mail.

TOC

1.1.3 Uncache hidden work (pending 8 hrs) id: 1333

TaskHeap caches WBS plan components for decent response time, but we can potentially reduce the memory footprint of this by removing any hidden plan components from the cache. These aren't needed for the outline, so response time should be the same.

TOC

1.2 Trap string length and auto truncate (pending 4 hrs) id: 1314

Trap string length violations up front so that the returned error message explains which field was a problem, what the current length is, and what the declared maximum length is. Provide a config flag in the DataManager to automatically truncate these values or throw an error on save.

[Eric Parker] 04aug05 trapping but not done yet

I tried to enter a name in TaskHeap that was too long, and it trapped it, but it didn't give any helpful info in the error as described so this is still open.

TOC

1.3 Tabular collection summary display (pending 16 hrs) id: 1266

When dumping out a collection of messages, it should be possible to put the summary field names across the top, and then dump out each of the elements formatted in a tabular way. The task here is to build the demonstration transforms for TaskHeapDemo, and add any supporting output tagging if necessary.

[Eric Parker] thoughts so far

Not really sure how to do this. Maybe an initial summary line with just the summary field names would be useful. Transforms could pick up on this line to write out an appropriate first table line with width percentages and whatnot.

TOC

1.4 Import logs progress (pending 2 hrs) id: 1313

The import processing should log which number object it's on, so you that you can see where it is at. Do this right before the insert call.

TOC

1.5 config editor dies with sand.flags dynamicselect (pending 4 hrs) id: 1334

The @sand.flags dynamicselect messes up the config editor so it spits out the "save parent before editing" placeholder. Fix this.

TOC

1.6 Messaging.html improvements (pending 6 hrs) id: 1309

Add a section in the beginning talking about basic usage. Call with a SandQueryMessage, get a SandCollectionMessage in return. Call with a SandUpdateMessage, get a SandUpdateMessage back. We need to cover the basics here first.

Note that in practice many times even single updates are wrapped inside of an AggregateUpdate message, since that saves on comm declarations and authorization processing.

TOC

2 Near (Plan 463 hrs) id: 1176

plan components:

2.1

SAND framework and functionality

SAND development process

Near term work to be done after immediate work.

TOC

2.1 SAND framework and functionality (Plan 353 hrs) id: 1336

plan components:

2.1.1

Configuration and Control

UI and SANDForms processing

Persistence and query processing

Messaging

Work related to features of the application framework generated from the SAND
declarations, or general utilities available to application deployments.

TOC

2.1.1 Configuration and Control (Plan 56 hrs) id: 1304

plan components:

2.1.1.1

warn about uninitialized comms

Host-specific launch

Explicit MBean reset (hot redeploy)

more flexible XMLSerializer

Work related to configuration management and runtime control.

TOC

2.1.1.1 warn about uninitialized comms (pending 8 hrs) id: 1232

When a communication path is not configured, we should probably warn about that at startup and/or on saving the configuration in the config editor. It's too easy to not hook something up that needs to be.

TOC

2.1.1.2 Host-specific launch (pending 8 hrs) id: 1307

SandBossRootNode needs to launch only the nodes that should be launched for the server it is currently on. We can't rely on figuring this out from the network environment, so we need to use a setting. To figure out the current host, the root will look for
1. A "sandhostname" system property.
2. A "SANDHOSTNAME" environment variable.
3. A "hostname" system property.
4. A "HOSTNAME" environment variable.
If none of these are found then the hostname is "".

The host name value can be set to a single name, or a CSV of names. The root will launch all node instances declared to be running on the host(s) defined. The reserved value "SAND_ALLNODESLOCAL" directs the root to launch all nodes regardless of which server they are declared to be running on. If hostname ends up as "" that is treated as SAND_ALLNODESLOCAL by default.

SandRoot exposes two new methods: getHostName() and overrideHostName(String). The first is a general utility and the second allows things like XHTMLSandUIServlet to force local launch.

We log what the hostname is when we figure it out, or when it is overridden. It should be clear from the log what host we are on.

TOC

2.1.1.3 Explicit MBean reset (hot redeploy) (pending 16 hrs) id: 1320

Currently hot deploy of a war can fail if the node control MBeans were already registered. We need to check for an existing registration and reset it as necessary on startup.

We can't rely on appropriate signaling for teardown. Even if this were generally reliable, we would still want the reset capability.

TOC

2.1.1.4 more flexible XMLSerializer (pending 24 hrs) id: 1329

The XMLSerializer should avoid using array element totals, or use them just as an initial guide. It should avoid using indices or other values that make it hard to insert new array elements during hand editing. It should also fall back to using a full SAX parser if reading fails.

By making these changes, we retain the speed used for messaging, but we also gain the capability of being able to easily hand edit the config and sandui files, and/or have other editors built for these that aren't tied to our XMLSerializer.

TOC

2.1.2 UI and SANDForms processing (Plan 168 hrs) id: 1278

plan components:

2.1.2.1

Actions on collections

Thousands separator for numbers

UIFormContext improvements

UI error handling

Screen scraper for emailing reports

Field triggers

Work related to SANDForms, SandUI or other general UI behavior.

TOC

2.1.2.1 Actions on collections (pending 32 hrs) id: 1294

When working with a SandCollectionMessage, we want to enable the selection of multiple instances to apply a single function to. For example you might want to select 13 out of 20 instances to delete.

To handle this and numerous other multi-select situations, we will provide a "Select" button for collections. When first clicked, this puts checkboxes in front of all the collection elements, and displays "Mark All", "Clear All", and "Select" buttons. The second select click restricts the collection to the checked items.

Applications can (as usual) provide their own custom buttons to handle deleting, accepting, or otherwise manipulating multiple items.

TOC

2.1.2.2 Thousands separator for numbers (pending 8 hrs) id: 1316

Change the default numeric output to use number formatting rather than the default toString conversion. That way we can get the commas for large numbers in there.

TOC

2.1.2.3 UIFormContext improvements (Plan 120 hrs) id: 1241

plan components:

2.1.2.3.1

note recursive edit

near-binary serialization of state objects

stack push and pop capability

cancel tree for contained add

Output text severity

Our currrent UIFormContext model organizes all state into an efficient structure that works well under most circumstances, but there is room for improvement. This plan organizes identified or potential improvement work.

TOC

2.1.2.3.1 note recursive edit (pending 8 hrs) id: 1242

Scenario:
Assume that ClassA contains an array of ClassB references, and ClassB in turn contains an array of ClassC references.

If a user edits InstanceA and makes a new InstanceB. They cannot add an InstanceC to the new InstanceB, until after InstanceB and the modified InstanceA are saved. This is because there is not enough room in the UIFormContext to store this state. Some indication of this needs to be provided when editing InstanceB.

One possibility here is to indicate that adding a new InstanceC is possible, but is disabled until the previous instance is saved. Another solution is to provide the editing buttons for instanceC, and if clicked, prompt the user to save the outstanding InstanceA and InstanceB changes. We would need to extend the UserQuery to provide this kind of prompting.

[Eric Parker] UserQuery extension useful

TOC

2.1.2.3.2 near-binary serialization of state objects (pending 8 hrs) id: 1243

Objects which are part of the current state need to be saved in a tight binary format. Although it is more readable to have them serialized out as individual hidden parameters, this takes up a huge amount of data which needs to get transferred back and forth. Instead, this state needs to be stored as a single hexified binary serialized value to save transmission bandwidth.

[Eric Parker] Add explanatory text

I personally hate viewing source and finding a pile of hexified crap, so we should dump a URL in a comment where people can get details of what's going on.

TOC

2.1.2.3.3 stack push and pop capability (pending 8 hrs) id: 1245

The idea here is to be able to take the entire UIFormContext and push it onto its own stack. That way we can recursively edit references without any depth limitations. The UIFormOwner.formSave processing would need to be called on CANCEL when there is a stack, but otherwise this seems possible. Needs spec.

TOC

2.1.2.3.4 cancel tree for contained add (pending 80 hrs) id: 1246

Sourceforge RFE
http://sourceforge.net/tracker/index.php?func=detail&aid=699993&group_id=46466&atid=446225

This needs to be considered as part of the standalone config editor tool.

TOC

2.1.2.3.5 Output text severity (pending 16 hrs) id: 1234

A UI needs to know the severity of the output text. If this is an error in processing, then it might be displayed in red, if this is a message saying that the data was saved successfully, then it probably would not be. The severity needs to follow the log level, and be available for transformation.

[Eric Parker] Use with SandTransmitMessage error array

If we modify UIFormContext to have an array of messages, each with a severity level, then we could code that up for XHTML color transformation so that error messages come out in red and informational messages don't.

TOC

2.1.2.4 UI error handling (Plan 8 hrs) id: 1306

plan components:

2.1.2.4.1

protect webapp from partial form submission

Work related to preventing or handling errors and exception conditions in the UI.

TOC

2.1.2.4.1 protect webapp from partial form submission (pending 8 hrs) id: 1236

If someone clicks a button before a form has a chance to fully download, then we may potentially lose state, leading to bad data reconstruction and potentially bad processing. For DEREF operations this is not critical, but for SAVE or SELECT it could be bad. See about providing an end-of-data marker or other strategy to prevent this from happening.

We should look into how other people handle this, however any double refresh of the page or other hacking that affects the display is not a good idea.

TOC

2.1.2.5 Screen scraper for emailing reports (Plan 0 hrs) id: 1315

plan components:

Write a basic screen scraper framework for TaskHeap using java commons HttpClient as a base. Use this to capture the contents of a printer friendly report page with a heap summary, which can then be emailed or otherwise manipulated. This is useful as a demonstration for how applications can handle runtime reports in general, but it's not a major priority in terms of actual TaskHeap functionality.

TOC

2.1.2.6 Field triggers (Plan 0 hrs) id: 1254

plan components:

A field trigger can be declared via an @sand.fieldtrigger struct field tag, and causes the associated method in a FieldTriggerHandler interface implementation to be called at run time, with a representation of the form display. The FieldTriggerHandler processes the form display, doing things like altering the possible values of other fields and the like.

A possible example implementation would be for the struct rendering to produce client side javascript associated with the specific field, which would then call the FieldTriggerHandler processing as a javascript function. The idea is to provide client-side dynamic forms without having to worry about doing this kind of thing in transformation templates. Needs spec.

TOC

2.1.3 Persistence and query processing (Plan 65 hrs) id: 1279

plan components:

2.1.3.1

automatic database reset

Smart quoting of strings in match value

Subselect query support

Work related to storing and retrieving persistent message instances.

TOC

2.1.3.1 automatic database reset (pending 24 hrs) id: 1225

This was previously called "autogen ClearDatabase.sql" but that's HSQL specific and doesn't really solve the whole problem. Here's the use case: you have a demo deployment set up that you want to frequently reset to a known starting state so you can re-run the same script or rebuild the playspace.

In terms of TaskHeap, you want a "reset database" button on the Admin screen that will delete everything in the database, and then load the required initial data, then import the application data, then restart the whole application to reset the state and caching.

To do this we need
1. A config parameter for the DataManager to allow/disallow reset
2. Create a DataResetStruct in apps/basics (see DataImportExportStruct)
3. Set up the TaskHeap button, message plumbing etc
4. Get the database reset and initial data load happening
5. Get the automatic data import happening
6. DataManager calls systemwideShutdown(SHUTDOWN_ERROR_RESTART_GLOBAL)

Sourceforge RFE
http://sourceforge.net/tracker/index.php?func=detail&aid=819294&group_id=46466&atid=446225

TOC

2.1.3.2 Smart quoting of strings in match value (pending 4 hrs) id: 1277

If we are matching a string field called "name", we might specify a match value of "Sue OR Mary". In actual fact this needs to written as
"\"Sue\" OR \"Mary\"" to be processed correctly. We should provide some heuristic preprocessing in these cases so if an expression can be tokenized on whitespace we let it go through.

TOC

2.1.3.3 Subselect query support (Plan 37 hrs) id: 1288

plan components:

2.1.3.3.1

Note no advanced matching in matches method

Query string serialization

IN/EXCLUDE matching for longs

Authorizer support for subqueries

We want to support the equivalent of SQL subselects so a query can specify that a given value is IN/NOT IN another query. A typical example is retrieving Readers that are not also Resources.

TOC

2.1.3.3.1 Note no advanced matching in matches method (pending 1 hrs) id: 1290

The matches method generated for each SandQueryMessage needs commentage describing that it does not handle dereferencing operations (for example a PlanQuery specifying "taskPhaseID.name = proposed"), or other advanced query processing like subselects. This kind of processing is why databases were invented, so that's where we draw the line.

A generalized matcher that can handle the dereferencing and subselects is effectively a DataManager implementation (or at least a very smart cache). This kind of thing is handled on a per application basis as needed.

TOC

2.1.3.3.2 Query string serialization (pending 4 hrs) id: 1289

Allow for serialization of SandQueryMessages by providing toText and fromText methods in the generated classes. So toText of a ResourceQuery for username eric would come out as

ResourceQuery username = "eric"

And fromText("ResourceQuery username = \"eric\"") would reconstruct the object.

The methods need to be symmetric, but fromText does not need to be as forgiving as the general query processing in terms of quoting or implied equality operators.

TOC

2.1.3.3.3 IN/EXCLUDE matching for longs (pending 16 hrs) id: 1291

Extend the query processing to allow the IN or EXCLUDE operators for any long. So for example we could have a ReaderQuery with a match of

"uniqueID","EXCLUDE ResourceQuery"

This would trigger a NOT IN subselect clause with "SELECT uniqueID FROM Resource". To avoid issues with String fields containing values of "in" or "exclude", this matching is limited to longs.

TOC

2.1.3.3.4 Authorizer support for subqueries (pending 16 hrs) id: 1292

The Authorizer needs to be extended so it checks for subqueries. Someone who has no access to Resources should not be allowed to specify a ReaderQuery EXCLUDE ResourceQuery. We have a similar issue for dereferencing using dot notation. The unpacking process for both of these needs to be handled by the Authorizer processing.

TODO: This needs spec.

TOC

2.1.4 Messaging (Plan 64 hrs) id: 1248

plan components:

messaging error handling

Const message instances

Tasks around messaging and distributed communications.

TOC

2.1.4.1 Native WS messaging (Plan 20 hrs) id: 1281

plan components:

2.1.4.1.1

Full exception bulletproofing

Client .jar ant task

QuickWSMessager

To allow client applications to communicate with the server application over HTTP (the only protocol available in some proxy firewall setups), we want to provide a simple web services interface using the same AuthWrapper messaging used for secure comms. This is in contrast to a SOAP wrapper, which is scoped separately. This plan holds work related to a serialized AuthWrapper sent to the server via HTTP POST, with the results received as the response. Serialization is via org.sandboss.tools.util.XMLSerializer.

For broadcast, we serve a page holding the N latest broadcast messages collected as a SandMessage[] placed inside of an AuthWrapper. The client can poll this page periodically. The expecation is that the CommBridge will return an array of SandTransmitMessages with a sequence number to allow for client reconcilliation.

TOC

2.1.4.1.1 Full exception bulletproofing (pending 4 hrs) id: 1302

We never want to crash with a server 500 error, so make sure we trap all exceptions that occur during processing and return some kind of an error message inside of an AuthWrapper.

TOC

2.1.4.1.2 Client .jar ant task (pending 8 hrs) id: 1285

Create an ant task that will create a single deployment project subdir containing all the source needed for an external client. This includes all the generated sandmessages, supporting code like serializers and comm interfaces, and a relatively small set of the total utilities. This provides a base for an application to add whatever additional files it wants to make available, build the client.jar as a separate ant task, and then do whatever to make this available to the client app. This simplifies the client complexity and reduces the size of any download that is needed.

TOC

2.1.4.1.3 QuickWSMessager (pending 8 hrs) id: 1250

Our Quick WebServices Messager is a Messager implmentation that uses our XMLSerializer to send messages between machines via servlets. Since this also goes over the default port, it needs to play nicely with webapps.

Standalone GUI apps must be able to use QuickWSMessager. Note that in this case there is no servlet container.

[Eric Parker] mention Fast Web Service

In the comments for our QuickWSMessager we should refer to the Fast Web Services concept (WS using binary serialization) that Sun put forward in their

http://developer.java.sun.com/developer/technicalArticles/WebServices/fastWS/index.html

[Eric Parker] is pure J2SE possible?

TOC

2.1.4.2 SOAP messaging (Plan 8 hrs) id: 1280

plan components:

2.1.4.2.1

WS-I basic profile 1.0 (SOAP messaging)

The goal here is to create a service, which means creating a WSDL and publishing it to a registry.

Web services are primarily used for edge communications to/from the outside world. For communications within the app but across VMs, it should be no problem at all using our own "quick web services" interface, but nobody from outside of our build/release process has any business calling this directly, since the serialization will change with each data revision (the app could just as well be sending a binary stream, or using sockets). This is a useful default communications mechanism but it is not a basis for external integration.

We need some build support to produce the basics. Specifically we need Ant tasks that make it possible to:
1. Generate struct defs from WSDL (for ease of creating processing nodes). This is a pretty nice driver task for folks coming from pure SOA tools.
2. Generate a servlet shell and WSDL from an inmessage/outmessage specification. That's pretty nice for SAND folks needing to expose a web service. The security here is still evolving, but with the next spec revision supporting OSS XML, this should straighten out a bit. For now we just do the basics and assume they are over HTTPS.

TOC

2.1.4.2.1 WS-I basic profile 1.0 (SOAP messaging) (pending 8 hrs) id: 1249

It must be possible to easily create standards-based web services in sandboss using the container support for J2EE 1.4 SOAP calls. This is JAX-RPC with lookups via JNDI. Define how this works and implement the supporting generators.

TOC

2.1.4.3 JMS Messaging (Plan 4 hrs) id: 1286

plan components:

2.1.4.3.1

Automatic session recovery

Tasks related to Messaging over JMS

TOC

2.1.4.3.1 Automatic session recovery (pending 4 hrs) id: 1287

The AuthorizedJMSMessager should recover automatically when the session has been closed. So if it receives a javax.jms.IllegalStateException "cannot perform operation, session has been closed", then it should complain and then reinit to recover.

This happens if the JMS server gets restarted and sandboss doesn't.

TOC

2.1.4.4 messaging error handling (Plan 24 hrs) id: 1303

plan components:

2.1.4.4.1

SandTransmitMessage error array

Error and exception handling fixes and improvements.

TOC

2.1.4.4.1 SandTransmitMessage error array (pending 24 hrs) id: 1233

We should change SandTransmitMessage to have an array of error messages rather than just one. We can adapt this to preserve the simple interface, while still enabling an application to return multiple errors. This is particularly useful when an update fails due to multiple problems with the data. If you can catch that up front, then you can avoid multiple annoying save attempts.

TOC

2.1.4.5 Const message instances (pending 8 hrs) id: 1259

I think the caching issue we see on update failures (form still has the
changed data) is due to a common pattern:
- retrieve an instance from cache or other known location
- modify it
- wrap it in an update message and call to do the update
When the update fails, we have nonetheless modified the instance we were
working with.

The solution is to support immutable instances. So every message would
have a makeInstanceConstant() method which would flip a protected int
instanceProtection member from zero (MUTABLE) to one (CONST). Every
mutator method in the message would then check the isInstanceConst before
making a change to any data members.

Modification of a const message results in a runtime error being thrown.
We don't want this to be a standard exception since it causes all sorts of
unnecessary annoyance for non-const instances. The main use for this is
in the IDCache, a secondary use is in the UIFormContext.

TOC

2.2 SAND development process (Plan 110 hrs) id: 1337

plan components:

2.2.1

General SAND development

Work related to developing using SAND, including declarations, build, deployment management and related issues.

TOC

2.2.1 General SAND development (Plan 110 hrs) id: 1305

plan components:

Work related to generators, build, or general SAND development issues.

TOC

2.2.1.1 SAND intro doc (pending 16 hrs) id: 1310

Create an intro document describing SAND. Modeling this as following an "introduction to distributed systems" slideshow might bore some people in spots, but it's still the best format for most of our audience.

Write this up.

TOC

2.2.1.2 SAND error handling (Plan 24 hrs) id: 1230

plan components:

2.2.1.2.1

duplicate sand declarations

bulletproof scrub with new generator

build tracking of deleted struct decls

A plan for making SAND development more robust in the face of errors, or probable mistakes.

TOC

2.2.1.2.1 duplicate sand declarations (pending 8 hrs) id: 1231

When the same @sand.xyz tag is used more than once (usually a result of cut and paste), it can be difficult to see. Consider spitting out a build warning or failing the build when this happens.

TOC

2.2.1.2.2 bulletproof scrub with new generator (pending 8 hrs) id: 1238

You can't run "ant scrub" after adding a new generator. You get a SandBuildException: Could not find class when trying to run it. Recover from this better. On scrub, if there's no class found, then there probably isn't any cleanup to do either.

TOC

2.2.1.2.3 build tracking of deleted struct decls (pending 8 hrs) id: 1239

sourceforge bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=787779&group_id=46466&atid=446222

Deleting a struct decl causes the build to fail. This was working at one point and is apparently busted now. The comments describe the problem details and where to start.

TOC

2.2.1.3 build work (Plan 70 hrs) id: 1240

plan components:

2.2.1.3.1

Split deployment prefix into deployment and application

container independent mainbuild.xml

jar file versioning

Reregister MBeans on hot deploy

SandBuildDriver reset ant task

Other general open work on SAND/sandboss

TOC

2.2.1.3.1 Split deployment prefix into deployment and application (pending 32 hrs) id: 1322

Split the current DeploymentPrefix property into an ApplicationPrefix and a DeploymentPrefix. This allows optimum memory usage in a multi-app deployment environment. Things like XHTMLFormAdaptor use the ApplicationPrefix, since they can be shared across multiple runtime instances. Things like the JDBCPersister and supporting database code uses the ApplicationPrefix to generate code, which takes the DeploymentPrefix as a parameter of what tables to access.

TOC

2.2.1.3.2 container independent mainbuild.xml (pending 8 hrs) id: 1253

Sourceforge RFE
http://sourceforge.net/tracker/index.php?func=detail&aid=756781&group_id=46466&atid=446225

We need to get the JBoss and even the J2EE .jar links out of the core mainbuild.xml so that we use the same build across multiple SAND environments.

TOC

2.2.1.3.3 jar file versioning (pending 8 hrs) id: 1270

In addition to prefixing, we want to allow some form of suffixing to provide version identification based on the .jar file name itself.

TOC

2.2.1.3.4 Reregister MBeans on hot deploy (pending 16 hrs) id: 1274

Now that we are using generic MBeans which are registering both in JBoss and standalone Tomcat, the next step is to make them resilient on hot deploy. Currently hot deploy of a self-contained WAR fails because the MBeans are already registered. We need to destroy the existing instances and recreate them in this case.

TOC

2.2.1.3.5 SandBuildDriver reset ant task (pending 6 hrs) id: 1328

We need an ant task to nuke the SandBuildDriver so it can be reset. Currently it is not possible to do several top level independent ant builds within a single target, because the SBD context carries over. We need a way to tell the SBD when we are done with it.

TOC

3 Future (Plan 436 hrs) id: 1178

plan components:

3.1

BILoc deployment support

case-driven development

Active SANDForms

Good to do

Work to potentially be done in the future (not near term).

TOC

3.1 BILoc deployment support (Plan 0 hrs) id: 1296

plan components:

3.1.1

Application shell deployment

The web microserver

Browser interface localhost (BILoc) application deployments are local applications using the default browser for their display, with a micro webserver process for the application. Launching a BILoc deployment runs the application and opens a browser window set to the corresponding localhost:80 URL.

Advantages of a BILoc app:
- same application can be server-based or standalone
- lower learning curve for new application users
- thick clients identical to their thin client variants
- server UI skills applicable for standalone development
- UI look and feel normalized across a wide range of platforms

With support for BILoc, a SAND app can be deployed
- on multiple servers
- on a single server, shared server, or web enabled device
- on a single client

[Eric Parker] 14jul05 Graphical interface support

[Eric Parker] 16jul05 Not running off the browser

A BILoc app is NOT an applet. Apps running off the browser are subject to browser differences between vendors and versions, and they are not trusted like an installed application is. The whole point here is to have a real application.

TOC

3.1.1 Application shell deployment (Plan 0 hrs) id: 1330

plan components:

We need a way to install an application on a typical PC (Windows/Mac) that looks like any other app but in reality fires up an executable .jar (the application) and the default browser keyed to the main URL for the app. Need to figure out what tech to use for this, how the install build will work, and what the plumbing requirements are. Presumably java webstart may kick in somewhere here.

For extra credit have the same thing work for Linux boxes and Palm pilots too.

TOC

3.1.2 The web microserver (Plan 0 hrs) id: 1331

plan components:

Having the overhead of a full blown webserver just for our SAND app seems like overkill, but maybe there's something small available that we can use? If not, then we should look into avoiding the whole HttpServletRequest/Response architecture in favor of a streamlined implementation of our UIRenderInput interface. Really all we need is the param map and some way of listening on the socket nicely. Figure out how this plumbing will work.

TOC

3.2 case-driven development (Plan 420 hrs) id: 1216

plan components:

3.2.1

switch to store state in session

multiselect drop down support

dynamic config editor updates

use -linksource for javadoc

build process monitors warnings

localized XHTMLFormAdaptor

Advanced paging

polymorphic message collections

message struct version checking

@sand.link for javadoc

dynamicrefresh FieldTagFlag

Link.linkType=macro

@sand.flags blobpersist

general match expression query field

Work best handled as part of an ongoing project. In the absence of at least one driving real-world scenario, it's generally a bad idea to proceed. If someone requires the feature, and they are working with us, then we will make it happen. Otherwise it's tabled here.

TOC

3.2.1 switch to store state in session (pending 8 hrs) id: 1244

We should provide a switch for storing the state information in the session as opposed to with the client request. The session is more susceptible to things getting out of sync, but it saves transmission bandwidth.

TOC

3.2.2 multiselect drop down support (pending 8 hrs) id: 1273

The first stage of this is to generate a multiselect dropdown for enumint fields in the query message. Each multiselect item is related by OR.

Once that's happening, we want to be able to trigger this using some kind of a tag. Maybe @sand.reference my.struct.name fieldname combined with @sand.flags multiselectOR. Figure that out after the multiselect is working.

[Eric Parker] 14aug05 needs spec

This needs more spec. Maybe a string field with enumint tags and a multiselect flag would be a good way to deal with this? Then the result could be stored as a CSV of ints. On the other hand a straight String field with some additional display transformation might do this. Tabling this until there is a driving case.

TOC

3.2.3 dynamic config editor updates (pending 40 hrs) id: 1217

sourceforge bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=672238&group_id=46466&atid=446222

Basically the idea is to have the config editor notify the SandBossRoot so
the changes take place without having to restart the container. While
making the config editor a standalone tool will make things less
confusing, the dynamic restart is a good thing to have anyway.

[Eric Parker] hot deploy on build

At this point you need to redeploy the updated config.xml file, so maybe that will help eliminate some of the confusion around what's going on. Currently we don't pick up on this in a hot-deploy, but that may be possible. This might be worth a separate task.

TOC

3.2.4 use -linksource for javadoc (pending 8 hrs) id: 1218

Sourceforge RFE
http://sourceforge.net/tracker/index.php?func=detail&aid=617725&group_id=46466&atid=446225

Basically we want to be able to drill through to the source, but if this makes javadoc even slower then it needs to be a switchable option.

TOC

3.2.5 build process monitors warnings (pending 8 hrs) id: 1219

Sourceforge RFE
http://sourceforge.net/tracker/index.php?func=detail&aid=665051&group_id=46466&atid=446225

Our build has improved a bunch, but it would be nice to have it optionally stop if a warning was generated.

TOC

3.2.6 localized XHTMLFormAdaptor (pending 24 hrs) id: 1220

Sourceforge RFE
http://sourceforge.net/tracker/index.php?func=detail&aid=699679&group_id=46466&atid=446225

Basically extend XHTMLFormAdaptor and use the locale to lookup what the button text and suchlike should be.

TOC

3.2.7 Advanced paging (pending 80 hrs) id: 1276

Once we are able to return the total for a query, we can separate out
paging from the standard add/edit/delete functions onto a separate line.
This line should display the total, and then provide paging through a
standard text line of

prev 1 2 3 4 5 6 7 8 9 10 next (12050 total)

where each item is a link except for the current page. As you move up
past page 5, the entire contents scrolls, so for the 6th page you see

prev 2 3 4 5 6 7 8 9 10 11 next (12050 total)

and so on until you run out of data of pages on the right.

To implement this, we need to provide support in XHTMLFormAdaptor and
any other UIFormAdaptor implementations. The links all correspond to a
new button called "pager" which reads a request parameter of "pg" that
is set to a relative page number. So for example pg=1 means forward one
page and pg=-1 means back one page. This logic needs to be implemented
in AbstractFormManager, and needs to be supported by an additional
SandQueryMessage parameter.

The idea here is that the query processing will repeat the appropriate
number of queries to get to the next relative page. So if pg=5, then
we would repeat the query to the database 5 times and then retun that
result. A value of -3 would repeat the query 3 times in the reverse
direction.

TOC

3.2.8 polymorphic message collections (pending 80 hrs) id: 1222

Sourceforge RFE
http://sourceforge.net/tracker/index.php?func=detail&aid=699765&group_id=46466&atid=446225

Basically this is a security issue vs a demand issue. Waiting for a real driving case that isn't a case of sloppy design and/or inadequate authorization considerations.

TOC

3.2.9 message struct version checking (pending 60 hrs) id: 1223

Sourceforge RFE
http://sourceforge.net/tracker/index.php?func=detail&aid=699791&group_id=46466&atid=446225

This is excellent functionality which we should probably deliver on an as-needed basis. Waiting to drive the general solution from a real application so we can demonstrate appropriate testing and node reactions to old formats. Version checking follows the 80/20 rule, and we want a real case to provide the focus.

TOC

3.2.10 @sand.link for javadoc (pending 40 hrs) id: 1224

Sourceforge RFE
http://sourceforge.net/tracker/index.php?func=detail&aid=780840&group_id=46466&atid=446225

Basically putting explicit relative paths in the javadoc comments is ugly and kind of hard to maintain. The javadoc -link option is kind of scary due to the way it brings in absolutely everything, but our own linkage would not be too bad and would probably be very useful. Especially since we could then run some analysis or even generate our own "see also" type link lookups from the core classes out to the technology interface implementations. Nice to have.

[Eric Parker] Func req linkage

When generating a functional requirements document from the struct and node doc information, being able to trap internal linkage would allow us to have consistent traversal. Yet another reason why this is useful.

TOC

3.2.11 dynamicrefresh FieldTagFlag (pending 40 hrs) id: 1226

Sourceforge RFE
http://sourceforge.net/tracker/index.php?func=detail&aid=826951&group_id=46466&atid=446225

I want some more requirements and specification before putting a solution forward. Looking for a general solution involving field triggers.

TOC

3.2.12 Link.linkType=macro (pending 8 hrs) id: 1227

At the time of this writing we have form links, text links, and empty links (which are essentially invisible action holders). A macro link is a variant of a text link, where the value is determined through a callback to the UIFormOwner. This is useful for context-dependent dynamic linkage similar to what we can do in generated report text, but limited to within a given page.

Waiting for a driving case before implementing.

TOC

3.2.13 @sand.flags blobpersist (pending 8 hrs) id: 1228

This is analogous to @sand.flags stringpersist, but stores the result as a blob rather than a String. Need a real driving case for when stringpersist won't cut it.

TOC

3.2.14 general match expression query field (pending 8 hrs) id: 1229

In the query forms we generate, we should display a sandMatchExpression text entry where you can put raw match expressions, including access to subfields etc. Any entered text simply gets passed through raw. The field can be removed in display transformation when it's not needed.

What this does is provide join capability to the end user, but at the expense of increased form complexity. So far we've dealt with this kind of a perceived need using custom actions and other hooks. Not sure if this is a real need or not so waiting for a driving case.

TOC

3.3 Active SANDForms (Plan 0 hrs) id: 1295

plan components:

By using javascript together with a URL request to a broadcast message request source (utilizing our generated web service), it should be possible to dynamically refresh a collection display in response to realtime changes (at least at the level of the polling interval). This needs to be explored, since it obviates the need for building a standalone program to provide a stateful display.

TOC

3.4 Good to do (Plan 16 hrs) id: 1338

plan components:

3.4.1

build a JCA statement

Clean up query processing

Stuff we should do because it's the right thing to do, but that need an extra push to get up higher in the priority stack.

TOC

3.4.1 build a JCA statement (pending 8 hrs) id: 1251

Describe how we fit onto different messager implementations. Webservices should be pretty clear from our default implementation, and JMS is already covered in a few comments even though it could probably be brought together more cohesively. After we figure out the appropriate place to cover these, we also need a statement on how we work over JCA. This is important for people who want to work directly with higher level integration packages.

TOC

3.4.2 Clean up query processing (pending 8 hrs) id: 1308

The query processing SQL might be easier to understand if we defined a SQLQuery class with
String selectClause
String fromClause
String whereClause
String orderByClause
and then had methods to generate result SQL based on the target DB.

At this point what we have is working and relatively stable, so this is not the highest prio, but it might help to support more databases in the future and make things more readable next time we need to go in there.

TOC

4 Recycling (Plan 0 hrs) id: 1190

plan components:

4.2

Work done for release 1_6

Recently completed or closed

Work which was not done and won't be done. Storing these work definitions under recycling rather than just deleting them can help in tracking and allows work to potentially be revisited later if needs change.

TOC

4.2 Work done for release 1_6 (Plan 0 hrs) id: 1260

plan components:

4.2.1

fastXMLWS servlet generator

FastWSServlet implementation

FastWSClient class

add totalMatched field to SandCollectionMessage

add norefdisplay to FieldTagFlags

Support for Postgres

Refactor persistence generation

Cancel button clears outstanding updates

Outdenting a task causes orphaning

dump deployment prefix

default to save action after editing

Leave selection after move up/down

Update parent collection on Add

Recursive editing indicator

greater than and less than escapes

Clean up Resource display

Reset lastModifiedReason on update

prepulate ddmmmyy for notes subject

Avoid recreating demo data

Unsaved data not found for display

restrict import/export availability

Move CSVSerializer into apps util

A plan to hold finished or closed tasks so they are out of the way but can
still be viewed for reference purposes.

To reference deleted tasks, go to the tasks screen, click the find button, and enter "1" for the status.

TOC

4.2.1 fastXMLWS servlet generator (finished 6 hrs) id: 1282

In response to a sandui project declaration type="fastXMLWS", create a servlet shell that initializes the implClass servlet (for example org.sandboss.tools.UIProcessor.FastWSServlet) with name of the class implementing the CommBridge interface (specified in the ownerNodeNameLookup param). Fixed mode is assumed.

This is analogous to the current sandui webapp declaration, but source and decl files get written to the fastXMLWS directory rather than the webapp directory. Note that there is no target for supporting this (or any other custom interfaces) in mainbuild.xml. We should provide a sample declaration for TaskHeapDemo to build THD_FastWS.war for illustration purposes.

TOC

4.2.2 FastWSServlet implementation (finished 12 hrs) id: 1283

Create and implement org.sandboss.tools.UIProcessor.FastWSServlet. This is analogous to XHTMLSandUIServlet, but handles AuthWrapper messages via HTTP POST instead. If we can factor code between these, then we should.

The FastWSServlet has a CommBridge reference for support in doing its work. In response to an HTTP GET, it just returns the contents of getBufferedMessages. It does no parameter setting or other interaction with the CommBridge. The idea is that the CommBridge is probably a node with settings that can be controlled through the config and runtime control.

TOC

4.2.3 FastWSClient class (finished 20 hrs) id: 1284

For testing, and to make it easy to write client apps, we provide a FastWSClient class that is set up with some parameters (like the WS URL, onReceive callback class, polling interval etc) which it uses to handle the calls and polling needed for communications with the server over FastWS.

To make this readily available, we generate a simple console-based standalone java app as part of the SandUI project. The app reads a SandMessage in XML format from a local file (eg SampleRequest.xml), makes the call, and then dumps the results to the screeen. If the file is empty then it mentions that fact and then dumps the result of a GET. Provide a sample ant target that sets the parameters and calls the app. That makes it easy to test external connectivity at any time.

TOC

4.2.4 add totalMatched field to SandCollectionMessage (finished 24 hrs) id: 1221

Sourceforge RFE
http://sourceforge.net/tracker/index.php?func=detail&aid=699738&group_id=46466&atid=446225

Query stats are important, but can cause overhead. From our current work we know that retrieving a count (for example a count of the total number of tasks), without the overehead of actually transferring data can be critically important for generating a stats page or workflow summary.

[Eric Parker] count(*) is important

[Eric Parker] 9mar05 separate function from match

[Eric Parker] 9mar05 Intelligent paging wants totals

Intelligent pagination displays can make use of a total, so whenever possible we will fill that in even when the function is DATA, provided it doesn't add significant processing overhead. In other words if this is available from the stats on the query, then we fill it in, otherwise we leave the result as null and the caller will need to make a separate query with an aggregate function to retrieve the total.

TOC

4.2.5 add norefdisplay to FieldTagFlags (finished 8 hrs) id: 1293

In cases where an instance contains an extensive array of references to other objects (for example a batch processing control structure), the SANDForms display needs to be alerted that it should not retrieve each instance to generate a summary display form. While this is generally very helpful when following links between instances in the display, the overhead from these queries can be prohibitive in the batch control structure case. We need a norefdisplay tag to indicate that the summary info should not be retrieved.

TOC

4.2.6 Support for Postgres (finished 24 hrs) id: 1268

We want to be able to explicitely support Postgres. This might just work with the DefaultSQLStrutMapper, but we won't know until we try it. Given that the two major free databases right now are MySQL and Postgres, I think it's time to get Postgres happening for cash constrained deployments.

TOC

4.2.7 Refactor persistence generation (Plan 0 hrs) id: 1298

plan components:

4.2.7.1

sandpersist project declaration

requiredMode parameter