Menu
▾
▴
wqdata-team — Discussions regarding further development
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(14) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(17) |
Aug
(30) |
Sep
(23) |
Oct
(24) |
Nov
(11) |
Dec
(8) |
| 2004 |
Jan
(17) |
Feb
(8) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Shields, R. <Ran...@de...> - 2004-02-27 17:11:26
|
[2004-02-27] Thursday, built a bunch of examples using the various forms of data access. I had some problems trying to use Access for anything kind of complex so I loaded up SQL Server. Today, I am exploring how to use stored procedures and transactions. The goal is to be able to approach transactions that can be either handled by the database or within code. =20 -Rance. |
|
From: Ted H. <te...@hu...> - 2004-02-27 13:20:44
|
> [2004-02-27] Thursday, I implemented additional services to support > the Insert story. Today, I'm integrating those services with the > web page, and developing other services for the remaining stories. The CVS mailer for the team list seems to be down, so I thought I might post= a recap, in case everyone hasn't been checking out the code from= cpu-bridge. A controversial issue in application development is the separation of= presentation and business logic. Most everyone agrees that presentation and= business code should be separated. Maintaining presentation and business= code separately is the driving forces behind the "code behind" feature of= Visual Studio .NET. The most popular tact is to create a separate series of objects to provide= the business services. Since most business services involve data access,= these are often called "Data Access Objects". While we all agree that DAOs= are a good thing, not everyone agrees on what they should look like. There= isn't a formal framework or hierarchy for business objects or DAOs, so= everyone ends up rolling their own. In practice, I'm finding that Web Services make great DAOs. The= specification allows us to add or change services without "breaking" the= client. We can group like services together in any convenient granularity.= We can return string, primitive, and complex types (including DataSets).= And, .NET has made Web Services easy to create, maintain ... and even test!= To begin with, you don't need to do anything mysterious to create a Web= Service source file, just tag the methods you want to expose. Here's the= one I'm using now: http://cvs.sourceforge.net/viewcvs.py/wqdata/cpu-bridge/InetPub/cpu-bridge/S= ervices.asmx?view=3Dmarkup and here are the NUnit tests to go with it: http://cvs.sourceforge.net/viewcvs.py/wqdata/cpu-bridge/InetPub/cpu-bridge/S= ervicesTest.cs?view=3Dmarkup This code is exactly what we would write to implement this in a plain-old= code-behind architecture. The difference is that, as a Web Service, any= (authorized) application can access these services, from any platform (not= just .NET), from any server. So, if another division want to use one of our= Web Services, they can, without us interacting directly. We can share= services rather than code :) To make this very easy for clients to use, .NET provide a tool that can= generate a "proxy" objects. When we access the Web Service from our= application, we use the proxy instead of of the actual service. The proxy= handles all the Web Service red-tape, and we can just treat it like a local= object. The proxy is generated from the public description of the service,= rather than the .asmx source code file. You can generate a proxy without= accessing the C# source code. To use the Services from a page, we just do something like this: Nexus.Cpu.Bridge.Services services =3D new Nexus.Cpu.Bridge.Services(); string permitCode =3D services.GetPermitCode(); There is an extra step in that we need to re-generate the proxy after= changing the service, but that's easily reduced to a batch file. Likewise,= it's easy to use a batch file to compile the tests and proxy code into an= EXE for use by NUnit. Very slick in practice. (See CVS for some example= batch files.) So the plan is to complete the implementation of our "CPU Bridge"= application using Web Services for the business logic and data access. The= Bridge application is a web version of what CPU is using now, but we will= add the ability to merge permits and create a tracking list. We can also= use the same Access database they use now, so the applications can be used= side-by-side. :) The one downside to Web Services is that it does require an extra layer. If= the service were coded as a plain C# object, it would make a direct ODBC= call to the database. With WS, it makes a SOAP call to the service, and= then the service makes the ODBC call to the database. In practice, I doubt= that this will be a different that makes a difference. We could even make= lemonade by collecting the databases onto a dedicated database server,= optimized for that role. Something to note is that we can actually change the implementation of the= service without changing the clients. So, today's Access database could be= tomorrow's Oracle instance, but we could make that change without changing= the client applications. The interface to the Web Service would remain the= same. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-02-27 12:42:46
|
[2004-02-27] Thursday, I implemented additional services to support the= Insert story. Today, I'm integrating those services with the web page, and= developing other services for the remaining stories. -Ted. |
|
From: Shields, R. <Ran...@de...> - 2004-02-26 13:59:53
|
Wednesday, I delved further into the ASP.NET world by trying to convert the Web Matrix version of Phone Book to Visual Studio. During the process discovered the deficiencies in my knowledge of ASP.NET. This led into spending time building examples of all the server controls and Data access options available. =20 -Rance. |
|
From: Ted H. <te...@hu...> - 2004-02-26 12:45:43
|
Wednesday, I set up unit tests for the database/web services the pages will= be using. Today, I'm implementing the services we need to fulfill the= pages/stories. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-02-25 12:48:19
|
Tuesday, I explored alternative architectures for combining business logic= with the presentation logic, including "code-within", "code-behind", and= "service-behind". Today, I'm adding validation tags and the "get permit= number" to complete the Insert page, and moving on to the Update page. At= this time, I'm favoring the "service-behind" approach, where the page calls= web services from an embedded script. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-02-24 12:44:21
|
[2004-02-24] Yesterday, I setup a new module for the .NET cpu-bridge= application, brought over the pages and webtests from the prior= application, and coded the database logic for the Insert page. Today, I'm= adding validation and the get permit feature to Insert before moving on to= the other pages. Insert is using a simple "model 1" architecture now, but I= expect to be utilizing a "model 2"/"code behind" architecture as we bring= other pages online, and need to avoid duplication. -Ted. > On January 26, I extended the WizardAction so that "done" pages > were automatic options. Today, I'm working on migrating the CPU > "bridge" application to .NET and then extending it to support > merging permits. > > > -Ted. > > > ------------------------------------------------------- SF.Net is > sponsored by: Speed Start Your Linux Apps Now. Build and deploy > apps & Web services for Linux with a free DVD software kit from > IBM. Click Now! > http://ads.osdn.com/?ad_id56&alloc_id438&op=3Dclick > _______________________________________________ Wqdata-team mailing > list Wqd...@li... > https://lists.sourceforge.net/lists/listinfo/wqdata-team |
|
From: Ted H. <te...@hu...> - 2004-02-23 13:09:41
|
On January 26, I extended the WizardAction so that "done" pages were= automatic options. Today, I'm working on migrating the CPU "bridge"= application to .NET and then extending it to support merging permits. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-01-27 12:46:23
|
[2004-01-27] Yesterday, I extended the WizardAction so that "done" pages= were automatic options. Today, I'm continuing down the current ist of changes. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-01-26 14:15:42
|
[2004-01-26] Friday, I refactored the "storyboard" WebTest into separate= "storyboard" and "wireboard" tests, the latter being dependant on working= business logic/database persistence components, and started down the latest= list of prioritized tasks. > [2004-01-23] Yesterday, I completed the storyboard.xml build file, > except for the Add Wizard section. (We're going to use input from a > recent permit for that.) Today, I'm working down the new list of > changes. > 2004-01-22] Yesterday, I extended the webtests and modified > WizardAction to use "commit" rather than "submit" as the final step, > to avoid conflicts. Today, I'm completing this round of webtests > extensions and moving down the prioritzed list of changes to "lock down" development to date. > [2003-01-21] Yesterday, I completed the draft of the new webtest script and started coding it as a Ant build file. Today, I'm completing the= webtest build file and starting on the prioritized list of changes. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-01-23 13:04:42
|
[2004-01-23] Yesterday, I completed the storyboard.xml build file, except= for the Add Wizard section. (We're going to use input from a recent permit= for that.) Today, I'm working down the new list of changes. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-01-22 17:34:14
|
Weekly Status Journal
[2004-01-21] Over the last week (30 hours), we reshuffled the wizard pages=
according to client feedback, including the new "Flash Edit" story. We also=
renabled the security constraints and play-tested the application against=
Tomcat 5. Finally, To retain quality as we make the final round of changes,=
we developed a new WebTest script that presents the application's key=
features. Over the next session, we will make the final round of changes to=
stablize development to date. At this point, we should have a version of=
the pplication that can be put into play once the legacy module has been=
deployed and approved.
----
Iteration statistics:
* [000] "Too busy driving to get gas." - Hours: 30.0
* [001] "Those pesky users" - Hours: 2.5
* [007] "Elementary, my dear Data" - Hours: 5.0
* [008] "Down to business" - Hours: 7.5
* [017] "That's wizard, Harry!" - Hours 15.0
List statistics:
* wqdata-cvs Archives 2619 messages [no update since 01-14]
*=A0wqdata-team Archives 138 messages [no update since 01-14]
----
Roadmap:
+ Develop "legacy" module as a 1:1 replacement for Access database. This=
module will serve as a bridge between the old table layout and the new=
"reconciled" database. Displays and workflow will follow Access database as=
closely as possible. Implement "legacy" module using Velocity, FormProc,=
Maverick, Chain, iBATIS DAO, and iBATIS SqlMap, since they have active=
dot-net corollaries or prospects. This set of products is sometimes=
referred to as the "Providence framework suite".
/ Deploy legacy module and request dual entry of permits into Access=
database and "legacy" module of the web application. This step will confirm=
proper operation of both the web software and infrastructure. Redeploy if=
necessary. Also ship current iteration (#11) for client review with a set=
of a sample data.
/ Complete next set of stories for core CPU application.
- Move current CPU data entry to "legacy" modules; discontinue use of=
Access.
- Refine database schema (see RFCs); vet records imported from various=
legacy platforms; refine core module to match database.
- Deploy refined database (including "legacy" table); run dual entry.=
Redeploy if necessary.
- Move current CPU data entry to "legacy" module; discontinue use of=
Access.
- Complete stories for core CPU application (tracking events, materials=
lists, EPA reports, and so forth).
- Move current CPU data entry to "core" module; retain access to all=
"legacy" data.
- Develop "legacy" module for NDPES group, based on the Excel spreadsheets=
now in use; follow same deployment strategy.
- Move current NPDES data entry to "legacy" modules; discontinue use of=
Excel.
- Develop core NPDES module to replace legacy version.
- Move current data entry to core module; retain access to all "legacy"=
data.
- Complete remaining stories for core UAA (User Access and Authorization)=
modules, which is now using the current product architecture.
----
Meeting Notes:
These are notes about requirements by the users for modifications to the=
current CPU module for the adding a permit wizard.
--
The current wizard segments the process into (10) steps.
(1) County
(2) Plan Type
(3) Facility [Add New]
(4) Applicant ("owner") [Add New]
(5) Consulting Engineer [Add New]
(6) Area/Legal descriptions
(7) Media type/Materials/File found
(8) Fee paid, et cetera (ledger)
(9) Number of applications, plans, reports
(10) Date received, issued, reviewed; permit engineer; status
(11) Confirmation page with all fields
--
* Account for multiple permits from one application and the fee can be=
spread across multiple permits as well. This is a really important step and=
modifications must be made to get it right.
So, the flow should go like this:
(1) Start with county,
(2) get owner, and then be able to
(3) pick media for multiple permits.
That allows user to build multiple permits with the following step -
(4) pick permit type,
(5) pick facility,
(6) add facility contact info,
(7) pick consulting engineer,
(8) pick review engineer.
That is pretty much is the admin review process (or this whole add permit=
process). The individual details (step 7) is really done by the review=
engineer.
* Multiple permits get review engineer based on type and county. Get maps=
from Tim.
* The check number and description both need to go to a ledger type process=
to account for multiple checks, refunds, invoices, and different type of=
permitted things.
* Add a button for new entry at each place for both invoicing and project=
description.
--
Step 2. Need to add a bunch of permit types:
=A0=A0=A0=A0=A0=A0=A0=A0SLEX - only for OKC
=A0=A0=A0=A0=A0=A0=A0=A0WLEX - only for OKC
=A0=A0=A0=A0=A0=A0=A0=A0WLXC - single connection to a wastewater line
=A0=A0=A0=A0=A0=A0=A0=A0WLMC - multiple connections
=A0=A0=A0=A0=A0=A0=A0=A0SX - Supply water &=A0receive transport and treat wastewater
Steps 3 and 4 to add a new permit are backwards. Should pull up list of=
owners (towns) and then get the appropriate facility based on media type.=
Add a step for the actual contact to be used for a particular permit for=
the facility (facility contact modifier in datastore). On the facility and=
system steps (3 and 4), the user should have the ability to modify the=
address if necessary.
Step 5 (consultant) should be searchable by entering partial strings. The=
search fields should be either last name or company name.
Step 7. The media fields goes away since that is determined by the field=
plan type.
Step 9 needs to be done for each permit not just each application form.
Step 11 - last form that can be modified don't make them go back through=
wizard but rather to a full form that is pre-populated. Likewise, when=
clicking on edit a permit from any tracking list the users want to skip the=
wizard and go to full form w/pre-populated fields.
--
* Followup Tasks:
=A0 [Ledger Module]
Before adding the cannonical application(s), we can first open a ledger=
transaction for processing the fee. The ledger transaction would be setup=
like an invoice, so that one or more applications could be charged and paid=
together. This will generate a ledger invoice number that can be used to=
track each "application bundle" (applications being paid with a single=
instrument). Since we'd link the invoices are by application (owner), we=
could even generate a statement of account regarding all the application=
bundles.
To simplify the schema, we shold add a fk_invoice column to the permit, so=
that we can quickly determine whether an application is paid for not. (If=
the invoice is paid, the application is paid.) Applications in the same=
"bundle" would share the same value for fk_invoice.
=A0 [Multiple Applications]
After entering the detail for one application, we can offer a button on the=
final confirmation screen to "Add another application for this owner". The=
invoice number, application contact, and other pertinent details could=
carry-over.
=A0 [Full Form Edit ("Flash Edit")] (DONE)
=A0
To be useful the full form would have to have many of the same attributes of=
the multi-form wizard, or we'd have to distinguish between editable and=
non-editable fields. If we let them change the county, then the facility=
field will have to reset itself for the facilities in that county, and so=
forth. And then there is the issue of whether they can also add stuff=
whatever when "editing" the application (as opposed to "adding" it), and so=
forth.
I'm sure all these questions could be resolved, but it can get quite=
involved, and we'd end up building both a multi-form and a single-form=
wizard to do the same task.
One compromise, that's on the "later" list already, is to put [edit] buttons=
or links on the Permit Details screen (step 11). There are already dividers=
representing each page. So if they clicked the edit link for a section,=
they would go directly to that page in the wizard.=A0We could also add a=
smart "done" button that would come up when the form was in a valid state,=
and they could skip to the end after editing one field on one page, submit=
the change, and be done with it.
=A0
=A0 [Updating Related Details]
=A0
Well, as it stands, we're not displaying related details like the facility=
address, so it might hard to tell if it needs to be modified.:)
One idea would be to add more detail to the permit detail page (short and=
long versions). The long version would include the address detail for the=
contacts and so forth, and provide a link to goto the action for changing=
that detail.
So after setting up the application, and adding any new players, they'd be=
able to review all the detail on the permit details screen, and go off to=
make any changes, before submitting the application. (So labels like=
"county" and "facility" would be links that opened editing windows for the=
related record.) Since the wizard is fully re-enterant, there's not much=
extra work involved. Anytime they cick "Add Permit", they'd be right back=
where they left off. Any changed detail would be automatically reflected as=
well.
The same would be true if they came in from someplace else to edit the=
application. They could edit the records for any of the supporting records,=
or flash back to a page in the wizard to change any references.
=A0 [Lookup]
Contacts and Facilities should be searchable by entering partial strings.=
The search should extend over multiple fields, including code and name. For=
contacts, the company name should also be included. When searching, other=
filters should be excluded.
=A0 [Step Reorganization] (DONE)
(1) County
(2) Applicant ("owner") [Lookup] [Add New]
(3) Application contact [Lookup] [Add New]
(4) Fee and payment (creates invoice when request is submitted)
(5) Media Type [Add New]
(6) Plan Type [Add New]
(7) Facility [Lookup] [Add New]
(8) Consulting Engineer [Lookup] [Add New]
(9) Area/Legal descriptions
(10) Materials/File found
(11) Number of applications, plans, reports
(12) Date received, issued, reviewed; permit engineer; status
(13) Confirmation page with all fields
(14) Add another for this applicant/payment [goto (5)]
=A0 [Contact Roles]
=A0
* Instead of taking the perspective that there are different types of=
contacts, we should think in terms of a contact having zero or more roles,=
just as one of our user accounts may be in zero or more roles. In this way,=
the same "contact" can be used for the applicant, applicant_contact,=
facility_contact, and so forth.
In essence, we need to pull the "ck_contact" column out of the contact=
table, and create a roles table. The old ck_contact values can become keys=
to a role table. So, we'd have
=A0 roles: pk_contact, pk_role
=A0 role: pk_role, rolename
Where rolenames would be "address", "owner", "contact", "consultant",
In the facilities table, there would be a business logic constraint that the=
contact on the other end of "fk_facilty_consultant" should be represented=
as a consultant in the roles table. But that wouldn't be part of the=
default join.
Of course, the point of the roles table is so that we can display a list of=
"consultants" or "owners" for people to select, or for general reporting.
=A0 [Conforming Contact Roles]
If a Contact is selected from a lookup search, and is not already in a role=
appropriate to the field, the new role should be added when the application=
is saved.
=A0 [Schema changes]
UUIDs
* UUID keys need to be generated for sample data
=A0
Contact Roles
* Add roles table with pk_contact and pk_role columns.
* Add role table with pk_role and rolename columns.
* Seed tables with information from ck_contact column
* From contact table, remove ck_contact column (this will break hibernate)
Ledger Module
* Add ledger_invoice and ledger_payments tables, one invoice to many=
payments, one invoice to many permits.
=A0
* To permit table, add "fk_invoice" column to track which permits are=
charged to an invoice.
Application Contact
* To permit table, add "fk_applicant_contact" to retain a specific contact=
for an application.
----
Short term plans:
[thusted]
* Iteration lockdown
Tasks for iteration lockdown
(x) [103.4] Renable security constraints
(x) [100.3] Play test application under Tomcat 5 and Jetty
(-) [098.2] Create WebTest to walk through major features
(x) [223.3] Titles: page x of x - $wizard - Nexus - OK DEQ
(-) [100.3] Default date controls to 2004
(-) [223.3] Fix "double-decker" buttons
(7) [103.4] Permit Detail (Staff): Supress [EDIT] buttons
(8) [203.x] Select screens: Need select none option (for searches)
(9) [203.x] How to select pending?
(10) [203.x] Paging through large result sets
(11) [223.3] Hogsworth - Consider using a separate context for the aggregate=
data, rather than an ActionForm. So, we'd setup a "Wizard Catalog" (a Map)=
in a client's session scope. Each entry on the Map is another Map holding=
the state (or context) for the Wizard. As the ActionForms come by, we add=
the form's properties to the wizard's context. Then, at the end, we=
populate the target form from the wizard Context. This way we won't be=
coupled to a specific ActionForm subclass, and each page can use it's own=
request-based DynaActionForm with only the properties each page needs. If a=
later page updates a property for a prior page, the change would still be=
validated. The validator always steps back and revalidates lower pages. =A0If=
this happens, that page will be redisplayed (because of change (4)).
Prior short term plans:
* Step Reorganization (partial)
* Flash Edit
Tasks for Step Reorganization:
(x) Shuffle existing pages
(x) Prototype new pages
(x) Implement new pages when dependant tasks complete
Tasks for Flash Edit:
(x) [223.3] Jane! Put a Cancel button on all the pages.
(x) [223.3] Been there - Add EDIT button that will let us flip to any given=
page (cursor =3D page).
(x) [223.3] Caffeine free - Move nav buttons to the top of the screen, so=
they do not jump.
(x) [223.3] First come - If validation fails at any point, keep decrementing=
the page number and running validate again until we find the first page=
that fails (which is to say find the last page that passes, and then go to=
the one after that.)
(x) [223.3] Done that - Include a smart [DONE] button on each page that=
displays when a wizard is in a valid state and could be submitted (max page=
validates true).
----
Design issues:
+ [2003-08-06] We need a standard vocabulary that describes the entities in=
the application domain (Facility, Media Type, Facility Owner, Facility=
Contact, County, Permit Type, Permit Application Type ("Plan")). Working=
definitions for these terms could be added to the Stories, so that we can=
clearly define the responsibilities of the classes representing these=
entities.
+ [2003-08-06] We need a Request for Comment procedure so that approaches to=
defining =A0needs such as identifiers and terms can be circulated to=
interested parties and then adopted if a better alternative is not=
proposed.
----
Requests for comment:
+ [2003-08-13] Many of the legacy systems do not decompose individual names=
and store the full name in a single field. To accommodate importing this=
data, we are adding a full_name column to the contact table. In the=
business layer, we may have a "displayName" function that would return=
fullName if it is not blank or generate a fullName if fullName is blank.
+ [2003-08-13] Our current approach to handling the contacts may be naive.=
Right now, if a person is both an Applicant and a Facility Owner, their=
information is stored twice, as if Applicant and Facility Owner were=
separate tables. Instead, we should have a second contact_roles table. This=
table would be a standard many-to-many table that would store a record with=
the contacts primary key and the "class key" indicating their role. If a=
contact exists but is used in a different role, then the same contact=
record could be reused. This would also avoid problems in generating more=
than one contact code for the same person at the same address.
######
|
|
From: Ted H. <te...@hu...> - 2004-01-20 13:10:32
|
[2004-01-20] Yesterday, I renabled the security constraints and play-tested= the application against Tomcat 5 in order to develop a WebTest script for= presenting the application and to develop a prioritized list of the next= changes we need to make. Today, I'm continuing the development of the= script and task list. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-01-19 12:40:39
|
[2004-01-19] Friday, I completed the "reshuffling" of the Add Permit Wizard.= This morning, I'm reviewing the application and developing a prioritized= list of remaining issues, with an eye to complete the application through= retrieving and adding a permit application and merging an application. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-01-16 12:37:01
|
[2004-01-16] Yesterday, I reshuffled the wizard pages according to client= feedback, prototyped a new page (applicant_contact), and completed the= first two tasks of the Flash Edit story. Today, I'm continuing down the= Flash Edit list. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-01-15 13:35:04
|
[2004-01-15] Tuesday, I developed a plan of action regarding changes to the= Add Permit wizard to meet client's feedback. Today, I'm working on the= implementation of those changes. On Wed, 14 Jan 2004 10:37:20 -0500, Ted Husted wrote: > [2004-01-14] Monday, I completed the setup of Commons Chain and > CommandAction, to supercede DomainAction. Today, I'm refining the > Add Permit workflow, per client's feedback. On Tue, 13 Jan 2004 11:06:12 -0500, Ted Husted wrote: > [2004-01-13] Yesterday, I setup a CommandAction to replace the > DomainAction and made several changes to the Maven setup files. > Today, I'm looking at using the Living Logic Workflow package to > implement the changes resulting from client feedback. On Mon, 12 Jan 2004 08:04:29 -0500, Ted Husted wrote: > [2004-01-12] Friday, I started migrating services to commands. > Once that is complete, I can help out with refining the Add > Permit workflow, per client's feedback. |
|
From: Ted H. <te...@hu...> - 2004-01-14 17:12:31
|
Weekly Status Journal
[2004-01-14] Over the last week (15 hours), we completed the setup of the=
new wqdata4 module, which is using Maven for the build environment. This=
work included the setup of XPlanner, Commons Chain, CommandAction, DbUnit,=
and WebTest Canoo. We considered some different workflow packages, but=
elected to stay with the current WizardAction. This week we will be=
refining the Add Permit workflow pursuant to client feedback and extending=
the WizardAction as needed.
Over the last week, we setup a new module to continue development on the=
main CPU application. Over the next week, we will be adjusting the Add=
Permit wizard according to suggestions made during client's review. The new=
module is using Maven as a build system, which will help us manage=
dependencies, both between our own projects and with external projects. We=
are also moving the iteration tracking to the XPlanner database system.
----
Iteration statistics:
* [000] "Too busy driving to get gas." (2002-08-19 to 2004-08-18) - Hours:=
Estimated 104.5, Actual 25.0, Remaining 67.0
* [007] "Elementary, my dear Data" (2003-02-20 to 2004-05-09) - Hours:=
Estimated 20.0, Actual 5.0, Remaining 15.0
* [017] "That's wizard, Harry!" (2003-12-31 to 2004-01-20) - Hours:=
Estimated 40.0, Actual 2.5, Remaining 37.5
List statistics:
* wqdata-cvs Archives 2619 messages [+34]
*=A0wqdata-team Archives 138 messages [+6]
----
Roadmap:
+ Develop "legacy" module as a 1:1 replacement for Access database. This=
module will serve as a bridge between the old table layout and the new=
"reconciled" database. Displays and workflow will follow Access database as=
closely as possible. Implement "legacy" module using Velocity, FormProc,=
Maverick, Chain, iBATIS DAO, and iBATIS SqlMap, since they have active=
dot-net corollaries or prospects. This set of products is sometimes=
referred to as the "Providence framework suite".
/ Deploy legacy module and request dual entry of permits into Access=
database and "legacy" module of the web application. This step will confirm=
proper operation of both the web software and infrastructure. Redeploy if=
necessary. Also ship current iteration (#11) for client review with a set=
of a sample data.
/ Complete next set of stories for core CPU application.
- Move current CPU data entry to "legacy" modules; discontinue use of=
Access.
- Refine database schema (see RFCs); vet records imported from various=
legacy platforms; refine core module to match database.
- Deploy refined database (including "legacy" table); run dual entry.=
Redeploy if necessary.
- Move current CPU data entry to "legacy" module; discontinue use of=
Access.
- Complete stories for core CPU application (tracking events, materials=
lists, EPA reports, and so forth).
- Move current CPU data entry to "core" module; retain access to all=
"legacy" data.
- Develop "legacy" module for NDPES group, based on the Excel spreadsheets=
now in use; follow same deployment strategy.
- Move current NPDES data entry to "legacy" modules; discontinue use of=
Excel.
- Develop core NPDES module to replace legacy version.
- Move current data entry to core module; retain access to all "legacy"=
data.
- Complete remaining stories for core UAA (User Access and Authorization)=
modules, which is now using the current product architecture.
----
Requests for Comment:
+ [2003-08-13] Many of the legacy systems do not decompose individual names=
and store the full name in a single field. To accommodate importing this=
data, we are adding a full_name column to the contact table. In the=
business layer, we may have a "displayName" function that would return=
fullName if it is not blank or generate a fullName if fullName is blank.
+ [2003-08-13] Our current approach to handling the contacts may be naive.=
Right now, if a person is both an Applicant and a Facility Owner, their=
information is stored twice, as if Applicant and Facility Owner were=
separate tables. Instead, we should have a second contact_roles table. This=
table would be a standard many-to-many table that would store a record with=
the contacts primary key and the "class key" indicating their role. If a=
contact exists but is used in a different role, then the same contact=
record could be reused. This would also avoid problems in generating more=
than one contact code for the same person at the same address.
----
Design Issues:
+ [2003-08-06] We need a standard vocabulary that describes the entities in=
the application domain (Facility, Media Type, Facility Owner, Facility=
Contact, County, Permit Type, Permit Application Type ("Plan")). Working=
definitions for these terms could be added to the Stories, so that we can=
clearly define the responsibilities of the classes representing these=
entities.
+ [2003-08-06] We need a Request for Comment procedure so that approaches to=
defining =A0needs such as identifiers and terms can be circulated to=
interested parties and then adopted if a better alternative is not=
proposed.
######
|
|
From: Ted H. <te...@hu...> - 2004-01-12 13:04:19
|
[2004-01-12] Friday, I started migrating services to commands. Once that is= complete, I can help out with refining the Add Permit workflow, per= client's feedback. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-01-09 13:10:13
|
[2004-01-09] Yesterday, we reviewed the project status, made some short-term= plans, and laid the groundword for our next steps. Today, I'll be migrating= the old CPU "services" to Commons Chain "commands". This task will decouple= the old persistence layer (Hibernate) from Struts, so that we can migrate= to the new persistency layer (SqlMaps) at our leisure. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-01-08 13:10:55
|
[2004-01-08] Yesterday, I imported the new wqdata4 module, setup XPlanner= for iteration tracking, and prepared the weekly status report. Today, I'm= going to amend the Add Permit workflow per client feedback. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-01-08 13:10:30
|
Weekly Status Journal
[2004-01-07] Over the last week, we setup a new module to continue=
development on the main CPU application. Over the next week, we will be=
adjusting the Add Permit wizard according to suggestions made during=
client's review. The new module is using Maven as a build system, which=
will help us manage dependencies, both between our own projects and with=
external projects. We are also moving the iteration tracking to the=
XPlanner database system.
----
Iteration statistics:
* [017] "That's wizard, Harry!" (2003-12-31 to 2004-01-20) - Hours:=
Estimated 40.0, Actual 0.0, Remaining 40.0
List statistics:
* wqdata-cvs Archives 2585 messages
* wqdata-team Archives 132 messages
Additional statistics will be available in the next report, based on the=
Maven and XPlanner reports.
----
Roadmap:
+ Develop "legacy" module as a 1:1 replacement for Access database. This=
module will serve as a bridge between the old table layout and the new=
"reconciled" database. Displays and workflow will follow Access database as=
closely as possible. Implement "legacy" module using Velocity, FormProc,=
Maverick, Chain, iBATIS DAO, and iBATIS SqlMap, since they have active=
dot-net corollaries or prospects. This set of products is sometimes=
referred to as the "Providence framework suite".
/ Deploy legacy module and request dual entry of permits into Access=
database and "legacy" module of the web application. This step will confirm=
proper operation of both the web software and infrastructure. Redeploy if=
necessary. Also ship current iteration (#11) for client review with a set=
of a sample data.
/ Complete next set of stories for core CPU application.
- Move current CPU data entry to "legacy" modules; discontinue use of=
Access.
- Refine database schema (see RFCs); vet records imported from various=
legacy platforms; refine core module to match database.
- Deploy refined database (including "legacy" table); run dual entry.=
Redeploy if necessary.
- Move current CPU data entry to "legacy" module; discontinue use of=
Access.
- Complete stories for core CPU application (tracking events, materials=
lists, EPA reports, and so forth).
- Move current CPU data entry to "core" module; retain access to all=
"legacy" data.
- Develop "legacy" module for NDPES group, based on the Excel spreadsheets=
now in use; follow same deployment strategy.
- Move current NPDES data entry to "legacy" modules; discontinue use of=
Excel.
- Develop core NPDES module to replace legacy version.
- Move current data entry to core module; retain access to all "legacy"=
data.
- Complete remaining stories for core UAA (User Access and Authorization)=
modules, which is now using the current product architecture.
----
Requests for Comment:
+ [2003-08-13] Many of the legacy systems do not decompose individual names=
and store the full name in a single field. To accommodate importing this=
data, we are adding a full_name column to the contact table. In the=
business layer, we may have a "displayName" function that would return=
fullName if it is not blank or generate a fullName if fullName is blank.
+ [2003-08-13] Our current approach to handling the contacts may be naive.=
Right now, if a person is both an Applicant and a Facility Owner, their=
information is stored twice, as if Applicant and Facility Owner were=
separate tables. Instead, we should have a second contact_roles table. This=
table would be a standard many-to-many table that would store a record with=
the contacts primary key and the "class key" indicating their role. If a=
contact exists but is used in a different role, then the same contact=
record could be reused. This would also avoid problems in generating more=
than one contact code for the same person at the same address.
----
Design Issues:
+ [2003-08-06] We need a standard vocabulary that describes the entities in=
the application domain (Facility, Media Type, Facility Owner, Facility=
Contact, County, Permit Type, Permit Application Type ("Plan")). Working=
definitions for these terms could be added to the Stories, so that we can=
clearly define the responsibilities of the classes representing these=
entities.
+ [2003-08-06] We need a Request for Comment procedure so that approaches to=
defining needs such as identifiers and terms can be circulated to=
interested parties and then adopted if a better alternative is not=
proposed.
######
|
|
From: Ted H. <te...@hu...> - 2004-01-07 12:45:18
|
[2004-01-07] Yesterday, I completed the initial work on the wqdata4 module= so that it is now ready for import. Today, I'm working on the next set of= stories, in response to client's notes. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-01-06 12:33:55
|
[2004-01-06] Yesterday, I added an Ant build file to make it easier for us= to run common Maven targets. The apps section is nearly setup, I just need= to identify a few more Hibernate dependencies. (It works when I bring over= *all* the JARs from the old module, but that includes some we don't need= anymore.) Then, we can go to work on the change requests from the user= meeting. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-01-05 12:42:29
|
[2004-01-05] Friday, I setup the "shared" or "core" portion of the wqdata4= module, and started on the "apps" section, where the cpu application code= lives. Today, I'm completing the wqdata4 setup and reviewing the stories. -Ted. |
|
From: Ted H. <te...@hu...> - 2004-01-02 15:39:59
|
[2004-01-02] Wednesday, I started work on a wqdata4 module, where the new= development on the main CPU application will take place. Today, I'm= continuing that work and migrating the build to the Maven environment. -Ted. |
