TaskHeap



1 Immediate (Plan 51 hrs) id: 1175

plan components:

Top level organization plan for work to be done immediately.


TOC



1.1 specify descending order in query (pending 8 hrs) id: 1341

In the standard SandQueryMessage, you can specify a comma separated list of field names in the orderBy, and in some cases passing in a DESCENDING flag might work depending on the database being used, but there is no standard way of doing this.  We need to add a field for this, and handle it automatically.

Descending order is very useful when you want the newest object instances at the start of a collection display.  In practice, this hasn't been much of an issue because there have typically been intermediate runtime data structures that handle the ordering.  But this is not always the case.  The work here is to add the flag (default is ASCENDING) and provide support in the generated Persister implementation.


TOC



1.2 Simplified/Advanced find (pending 24 hrs) id: 1342

The current query form is quite powerful, allowing for full match expressions on every field of a class for search purposes.  However most users simply want to find an instance of an object based on some simple match criteria.  For example they may want to specify a status or type value and get all the results.  This is the most common type of find, and it is the most difficult to do with our current interface.  Multiselect capability for enumints would help, but the real issue is that we want to provide a simplified find interface.

The idea is to provide a simplified find, with just the uniqueID, short string fields, and enumint drop down boxes.  This would be a straight query by example interface.  The user would have the option to switch to advanced find which is equivalent to what we have now.

The work here is to allow for dual level find.


TOC



1.3 func spec node descriptions need detail (pending 8 hrs) id: 1348

Dump the configuration parameters and an I/O summary into the node descriptions in the func spec.  That way it works as a reference for what parameters are available and what their default settings are.  You would still have to go to the config to see the actual current settings, but this helps with the description.


TOC



1.4 func spec struct def detail (pending 8 hrs) id: 1349

The struct field descriptions need type information, default values, range constraints and other detail.  This is a great quick reference for reviewing the database structure so we don't want to double the size or make this really complex to read, but this info is important to understand.  Maybe a summary statement at the end of the field description?


TOC



1.5 Change the help link (pending 1 hrs) id: 1352

Nobody clicks on the help link because in most applications it represents a pile of useless noob info.  Change this to something like "User Manual" or something that gives and indication of what it actually is.


TOC



1.6 Rename the Export All button (pending 1 hrs) id: 1353

This should be called something like "Export Changes" or something to show what it really does.


TOC



1.7 change "save parent" note (pending 1 hrs) id: 1354

Change the [save parent before editing] recursive editing note to something more intuitive, like just [save first before editing] or somesuch.  The "parent" part of this is not intuitive when you are editing the instance.


TOC



2 Near (Plan 559 hrs) id: 1176

plan components:

Near term work to be done after immediate work.


TOC



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

plan components:

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:

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.1.5 Graphical config editor (Plan 0 hrs) id: 1345

plan components:

This plan holds work to create a graphical configuration editor.  We would like to graphically position nodes within servers, and replace the static configuration diagram referenced by the deployment intro.html with an image generated by the editing tool.

This could potentially run as an applet or similar dynamic extension of the existing config editor, or it could be a standalone app.  If standalone, it would be great if this worked as an eclipse (or other IDE) plug-in, but it shouldn't require it.

Like the existing config editor, selecting a node should bring up its deployment parameters, and allow for configuring inbound and outbound messaging.

For extra credit, have this same view access the running site to provide access to the control information.


TOC



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

plan components:

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


TOC



2.1.2.1 multilevel editing (Plan 136 hrs) id: 1355

plan components:

Work related to handling multi-level editing.  If MessageA has-a MessageB has-a MessageC, then when editing MessageA you can add a new MessageB, but at that point you currently need to save before adding a new MessageC.  The work here is to get past this for a smoother editing experience.


TOC



2.1.2.1.1 Use outstanding updates as stack (pending 40 hrs) id: 1356

The idea here is to handle multi-level editing by checkpointing (calling doActionOk automatically) as we traverse downward through referenced children, and then being smart on return.  So if someone edits MessageA --> MessageB --> MessageC and then saves, we are saving the checkpointed MessageA, and checkpointed MessageB along with the new MessageC.  If they cancel, then we are pulling the MessageB instance from the current updates and resetting the context into edit mode with that info.  We can continue to cancel our way up through the stack until we run out of outstanding updates in the uifc.

At the top level, if the object has a real uniqueID, then we just end with it.  If not, then we have to reinitialize on cancel.  But at each point in the editing chain the action is either save or cancel, which returns us up one level to where we were before.


TOC



2.1.2.1.2 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.1.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.1.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.2 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.3 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.4 UIFormContext improvements (Plan 24 hrs) id: 1241

plan components:

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.4.1 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


TOC



2.1.2.4.2 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


TOC



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

plan components:

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


TOC



2.1.2.5.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.6 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.7 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.2.8 Localization, i18n (Plan 0 hrs) id: 1339

plan components:

We need to write a localized XHTMLFormAdaptor, and handle translation of error and validation messages through a localized (or locale aware with property lookup) UIFormManager.  The app itself will have to deal with multiple locales also, probably by looking up contstant text values in a locale properties file.  It would be good to do one of these ourselves so we can set up the overall framework and make it easier for other people to deal with.


TOC



2.1.2.9 Include totals in pagination display (pending 24 hrs) id: 1344

To retrieve the current query result page, and a total results page typically requires two separate queries.  Add a deployment flag to trigger the creation of this kind of display.  By default this is off since it requires more overhead.


TOC



2.1.2.10 Integrated SandUI/action editor (Plan 0 hrs) id: 1346

plan components:

It would be useful if the SandUI editor created stubs for the corresponding action handlers.  So if I add a button, the activity query method and action handler method would be automatically created.  Name changes aren't really an issue since the display name is separate from the handler name, but stubs would be useful.


TOC



2.1.2.11 Rapid layout development (Plan 0 hrs) id: 1347

plan components:

The standard template site provides enough functionality to get demonstration filler data into the system with very little development, but most UIs require extensive customization to provide the desired look and feel.  We want to be able to perform most of this display customization without having to rebuild each time.

The idea here is to use the raw=true parameter to retrieve the raw XHTML output, save this to a file, and then work on the XSLT using this as the input.  We would like to recommend a good OS tool for this kind of work, and directions for how this works.  The idea is to enable designers to be able to go to work on the site directly without SANDev.  Figure out a good way to do this and write up the recommendation in the readme.


TOC



2.1.2.12 AJAX broadcast support (Plan 0 hrs) id: 1350

plan components:

It would be good to be able to declare an asynchronous notification function at the screen level that would be supported by a general broadcast mechanism within the UIFormOwner.  Basically this translates into a javascript shell method in the generated web page, which can be fleshed out to provide whatever functionality.  This is fed by the corresponding server method in the UIActionHandler.

Needs spec.


TOC



2.1.2.13 sand.help tag (pending 32 hrs) id: 1357

Create a new sand.help field tag that takes text describing a field for presentation to the user as a mouseover popup or similar mechanism.  This would go a long way towards making forms easier.

The work here involves creating the new tag, and then adding the necessary XHTML output to allow a transform to be able to pick up on it, then updating the existing transforms to demonstrate the functionality.


TOC



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

plan components:

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 sends a DataReset message over to the DataManager, which calls the Persister, which deletes everything in the database, and imports data from the export file.  On completion, the processing signals a global restart of the app.

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. Implement the database reset, followed by data import
5. DataManager calls systemwideShutdown(SHUTDOWN_ERROR_RESTART_GLOBAL)

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

[Eric Parker] 24oct05 auto data load works


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:

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:

Tasks around messaging and distributed communications.


TOC



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

plan components:

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.

[Eric Parker] 28dec05 or copy what you need


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

[Eric Parker] is pure J2SE possible?


TOC



2.1.4.2 SOAP messaging (Plan 8 hrs) id: 1280

plan components:

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:

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:

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:

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:

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:

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 444 hrs) id: 1178

plan components:

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


TOC



3.1 Strategic development (Plan 0 hrs) id: 1358

plan components:

Work that would provide a strategic technology advantage for SAND over other technologies that are out there.


TOC



3.1.1 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.1.2 BILoc deployment support (Plan 0 hrs) id: 1296

plan components:

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


TOC



3.1.2.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.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 As needed (Plan 444 hrs) id: 1359

plan components:

Development to be done as needed to increase the functionality and usability of SAND.


TOC



3.2.1 case-driven development (Plan 428 hrs) id: 1216

plan components:

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.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.1.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


TOC



3.2.1.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


TOC



3.2.1.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.1.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.1.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.1.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.1.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.1.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.1.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


TOC



3.2.1.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.1.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.1.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.1.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.2.1.15 Soft reference cache (pending 8 hrs) id: 1351

Extend NamedSingletonIDCache to create NamedSingletonIDCacheSoft which adds soft references.  Retrieval works the same way, but adding an instance can be specified as a java.lang.ref.SoftReference so that if the cache grows too large these values will be removed.  Have a method to register what class names are always soft references so that use is automatic.


TOC



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

plan components:

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.2.2.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.2.2.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:

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 Recently completed or closed (Plan 0 hrs) id: 1335

plan components:

Placeholder for work until we figure out where it ultimately belongs.


TOC



4.2.1 Filter to only your assignments (closed 8 hrs) id: 1213

Allow the initial display to be filtered to only the stuff assigned to you.
So if you want to focus in on your work, you can.

Closing this out.  If you want to find your tasks, go to the tasks screen, click find, and enter your resourceID.  The idea is for everyone to see the project so it becomes a shared view of what is going on.  Don't see a need for this.


TOC