TaskHeap



1 Immediate (Plan 18 hrs) id: 1175

plan components:

Top level organization plan for work to be done immediately.


TOC



1.1 Maximize concurrency (pending 8 hrs) id: 1391

Change the recalc fields to be dynamic so that a user can still update the database using an older copy of a task instance. This is important because with two people editing things in different parts of the heap, whoever triggers a recalc process first will pretty much automatically invalidate the other users work, even though they are probably just updating the description or status information. These updates need to occur without colliding. Spec this.


TOC



1.2 Return to heap view on successful save (pending 4 hrs) id: 1392

On a successful save of anything being modified on the Heap screen, return to the heap view. Doing a separate click for this each time sux.


TOC



1.3 Mark all tasks finished. (pending 2 hrs) id: 1394

Have a button when viewing a plan that will mark all the contained tasks completed. This is very helpful for bulk updates when a lot of work has been done but the heap hasn't been dealt with for a while.


TOC



1.4 default sort by deadline (pending 4 hrs) id: 1395

If a task has a dueDate set, then by default the containing Plan should have its elements automatically sorted by dueDate. Tasks with no dueDate should not move.


TOC



2 Near (Plan 617 hrs) id: 1176

plan components:

Near term work to be done after immediate work.


TOC



2.1 TaskHeap application improvements (Plan 46 hrs) id: 1364

plan components:

Improvements to the TaskHeap application.


TOC



2.1.1 computed relative date display and spin controls (pending 0 hrs) id: 1393

When showing the relative date, it would be very helpful to have the actual calculated date displayed on the right as a non-entry field for informational purposes. Next to it you could also have plus/minus buttons that would fine tune the relative date statement as needed to meet a specified target.


TOC



2.1.2 AJAX interface (Plan 26 hrs) id: 1389

plan components:

If it were possible to handle most of the heap display and processing on the client side, then things could perform better. Consider writing a GWT version of the interface.


TOC



2.1.2.1 Task editing as modal dialog (pending 20 hrs) id: 1388

For the AJAX interface, editing a task should be a modal dialog so we never actually leave the outline heap display.


TOC



2.1.2.2 Permanent edit on view toolbar (pending 6 hrs) id: 1369

Consider changing the display params toolbar to be in permanent edit mode so you can select from the dropdowns to change the view. We would still need a default button available to reset the params.

This may not be worth it since having this be an explicit action kind of hides the display options complexity from new users. People who know they want this can then click the "filter" button to edit the parameters. See how this goes. Possibly this can work differently in the AJAX interface than in the web interface.


TOC



2.1.3 Email change log notification to list (pending 8 hrs) id: 1381

Maintain a list of notification email addresses in the heap settings, and an annoyance threshold (default 2 hours). Modify the export so that it sends a summary of the most recently changed heap elements, and links, to everyone on the email list. That way everyone is made aware of changes as they happen.


TOC



2.1.4 OpenID authentication (pending 12 hrs) id: 1386

Support for standardized OpenID authentication and/or single sign-on in general.
Needs spec.


TOC



2.2 SAND framework and functionality (Plan 465 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.2.1 UI and SANDForms processing (Plan 324 hrs) id: 1278

plan components:

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


TOC



2.2.1.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.2.1.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.2.1.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.2.1.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.2.1.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.2.1.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.2.1.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.2.1.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.2.1.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.2.1.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.2.1.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.2.1.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.2.1.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.2.1.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.2.1.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. Codes need to be assigned to all application messages so that error messages can be translated via templates or lookup.

The current strategy for a localized product is to create a separate application and deployment. So for a Swedish version of TaskHeap I might have
   apps/TaskHeapSE
   deploy/TaskHeapSEMain
where the build copies all files over from the main TaskHeap projects except for the structs and templates, which are maintained separately.


TOC



2.2.1.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.2.1.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.2.1.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.2.1.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.2.1.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.2.1.14 Refactor XHTMLFormAdaptor for widgets (pending 32 hrs) id: 1370

Refactor the XHTML UIFormAdaptor implementation to make each output type into a separate widget, so we have a drop down select widget, number entry widget, date entry widget, text widget etc. Each widget is a separate java class, and the classes we load for each purpose are configurable. This allows the widgets to be overridden if desired, so for example you can swap out the date widget with something more advanced. It should also make things more readable.


TOC



2.2.1.15 Factor UI form object mapping in project template (pending 16 hrs) id: 1380

Mapping of aggregated UI display structs to/from their component data representations needs to be factored out in the template project. The idea would be to have a SiteUI class with general methods that are called from the formSave and display hook processing prior to save, prior to load, and post save. The goal is to have one place where this mapping occurs, so we can separate the framework control flow and mapping concerns. Currently it can be a bit overwhelming if all of this is done within the SiteUINode. Factor this in a real project, then apply that solution back into the framework here.


TOC



2.2.1.16 Query form help (pending 12 hrs) id: 1383

When presented with the standard query form, some kind of help filling in the query values would be useful. Putting this verbiage on the form makes it messier and doesn't constrain well in small display size environments, so some kind of popup or field value wizard is the way to go here. The simplest thing would probably be to generate some example queries in the field help so when they click on a field they can get more info. That's probably the first step in any case.

Another option would be to have a button that would populate the field with an open query value based on the field itself. So for a date it might show an example of less than or equal to the current time. For a name it might grab a sample name and then show the asterisk if it supports wildcard match. For a reference it might show the first ID it finds. For anything with a range, it would just dump in the range. An enum only needs help in the advanced form, at which point the first N values separated by OR might be good. Unless one of the values is OR in which case it should use the lowercase forrmat.

If we can generate a getSampleQuery method for each field, then we can use that to populate the help, and dump it out within a javascript function to populate the query form.


TOC



2.2.2 Persistence and query processing (Plan 77 hrs) id: 1279

plan components:

Work related to storing and retrieving persistent message instances.


TOC



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

[Eric Parker] 30may06 "contains" matching already works


TOC



2.2.2.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.2.2.4 Next/Prev buttons from instance view (pending 8 hrs) id: 1360

Having selected a specific instance from a collection view, we want to provide next/prev buttons at the instance display to allow walking through the collection elements. Basically this changes the findColl index and updates the display, triggering a call to the collection prev/next buttons as needed for data paging.


TOC



2.2.2.5 Remove indexing from XML serializer (pending 4 hrs) id: 1378

Work out the length and contents of array dynamically when loading. It's ok to dump out an array length for faster allocation on load, but if the length has changed then that needs to work also. So "written length" or "size hint" or something like that. Get rid of indices for each item within an array, figure it out from where we are reading from. Ok to leave an "original index" field or something for transforms to work with. Mostly just fix the load so it doesn't break if the XML is hand edited.


TOC



2.2.3 Messaging (Plan 48 hrs) id: 1248

plan components:

Tasks around messaging and distributed communications.


TOC



2.2.3.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.2.3.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.2.3.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.2.3.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.2.3.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.2.3.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.2.3.3 JMS Messaging (Plan 4 hrs) id: 1286

plan components:

Tasks related to Messaging over JMS


TOC



2.2.3.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.2.3.4 messaging error handling (Plan 8 hrs) id: 1303

plan components:

Error and exception handling fixes and improvements.


TOC



2.2.3.4.1 Field indicators for struct message (pending 8 hrs) id: 1379

Any transmittable struct message should include a field marker status array with one entry for each field and acc/mut methods for each field to set/unset marker information. A marker consists of a value and text. The text is optional and can be a localized lookup value. General error messages go in the existing error message return structure, the text in this case is just for additional detail. The value indicates required/optional and also valid/invalid. If several fields are inconsistent based on their combined values, then all the fields in the group are marked as invalid.


TOC



2.2.3.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.4 Configuration and Control (Plan 16 hrs) id: 1304

plan components:

Work related to configuration management and runtime control.


TOC



2.2.4.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.2.4.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.2.4.3 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.3 SAND development process (Plan 106 hrs) id: 1337

plan components:

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


TOC



2.3.1 General SAND development (Plan 106 hrs) id: 1305

plan components:

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


TOC



2.3.1.1 Show description in FileEditor file listing (pending 12 hrs) id: 1363

It would be extremely helpful to peer inside the .xml files we find and list out what kind of serialized object each one contains, and descriptive information about it.


TOC



2.3.1.2 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.3.1.3 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.3.1.3.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.3.1.3.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.3.1.3.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.3.1.4 build work (Plan 54 hrs) id: 1240

plan components:

Other general open work on SAND/sandboss


TOC



2.3.1.4.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.3.1.4.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.3.1.4.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.3.1.4.4 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



2.3.1.5 Rule based authorization. (Plan 0 hrs) id: 1384

plan components:

Authorization is rule based. Essentially there is an if/then for each update instance scenario, each field, and for match calls. The hardest part about definition and maintenance is locating the situation you want to trap. The hardest part of debugging this is figuring out what got applied and why. A rule-based approach with assistance in narrowing to the scenario that's being evaluated would go a long way towards simplifying this on both counts.

The first step here is to define some match definitions (a la OPS5) to show what rules would look like. My guess is that references to structs as WMEs works reasonably well and that a declarative structure could be built for this that would be more intuitive and easier to maintain.


TOC



2.3.2 Name what SAND is (pending 0 hrs) id: 1385

Structs and Nodes Development is an accurate name for what we are doing, but we need to describe the class of what SAND is. That's harder because it's not really the same as anything that's been done so far so the task here is to find a name for what kind of thing it is.

"Framework Generator" is good in that it describes what SAND does. Bad because our focus is not on becoming a spring or other existing framework generator. That's possible, but not the point.

"Automatic Source Maintenance" (describes the why of SAND somewhat)


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

[Eric Parker] 06jun07 Google to the rescue


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.1 recently completed (Plan 0 hrs) id: 1376

plan components:

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


TOC



4.1.1 Limit parent/child movement to outline (finished 0 hrs) id: 1390

Remove the capability to remove a child from a parent, or remove the parent reference from a child as far as the display goes. People can do this using the "move to current" format so things don't get confused. Should be a pure authorization change.


TOC



4.1.2 Relative deadlines (finished 0 hrs) id: 1375

When working on a deadline basis, you may have hundreds of tasks with various deadlines relative to where they are in the hierarchy. If this project is then being used as a template, that's hundreds of edits to set things up appropriately.

Provide for three dueTypes: None, Fixed and Relative. A relative deadline is set as +/-N hours/days/weeks relative to a parent plan or the heap in general as specified by a default in the HeapAttributes. The display calculates the relative deadlines based on the specified delta. Struct mods, form support, authorization and testing.

[Eric Parker] 25aug06 minimize deadlines

[Administrator] 16nov06 implementation plan

[Eric Parker] 03dec06 General heap deadline

[Eric Parker] 22sep07 Concept spec


TOC



4.1.3 Task description popup (finished 0 hrs) id: 1368

Have the first sentence (or first 60 chars or whatever) of the description show up as the title for the href in the main hierarchy view. That way you can mouseover tasks for more info when you're not sure what the name is.


TOC



4.1.4 Menus to top and general facelift (finished 0 hrs) id: 1367

Move the nav items to a top menu and simplify things for real use. Modified the names, help links, help text, and colors.


TOC



4.1.5 Current component and move icons (finished 0 hrs) id: 1366

The current component marker button and supporting buttons kind of suck. Make them transparent with help text so you can see what they do.


TOC



4.1.6 Tree address on far left (finished 0 hrs) id: 1365

The tree address (e.g. Task "1.2.3.1") belongs on the far left of the display since it is showing the outline.


TOC



4.1.7 Fix double spacing on paragraphs for Mac (finished 0 hrs) id: 1387

When entering descriptions for tasks, the paragraph separating newlines turn into double spaces in the paragraph separations. The fix was to not translate crlf (\r\n) into two <br/> tags in XMLTextProcessing.processToXML, which fixes the display.

Not sure why this started happening in the first place. Possibly the database encoding changed, leading to \r characters actually being recorded in the text and thus preserved for redisplay when previously they were stripped. In any case the display fix seems to be the right thing for now.


TOC



4.1.8 more flexible XMLSerializer (finished 0 hrs) id: 1329

The XMLSerializer relies on a _field attribute after each class that tells it what it is reading and where to insert it. This allows for fast serialization/reconstitution but makes it difficult to do any hand editing of XML files and makes it harder to do general calls via web services. The XMLSerializer is based around the readAttrVal method, which pulls several tokens from a StreamTokenizer. This is fast, but not resilient.

If XMLSerializer fails to read for any reason, it should attempt to read using an ExternalXMLSerializer. This is a new utility based on a SAX parser which will be slower but more resilient, allowing the XMLSerializer to handle a broader range of input. The work here is to generate the ExternalXMLSerializer, and the failover calls from the top level XMLSerializer read methods.

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



4.1.9 Update software development template (finished 0 hrs) id: 1382

The login and authorization task should specify that the time estimate is a multiplier times the number of struct definitions. So if you figure an average of 20 minutes to write the authorization and match restrictions for a struct, then the work hours would be the number of structs divided by 3.


TOC



4.1.10 SandTransmitMessage error array (finished 0 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.

Added an ErrorInfo to the AggregateUpdate. That allows communications for anything
significant, while leaving the existing error structure in place.


TOC