Re: [udig-devel] Target chat with Pablo

[quintona]

To follow up to this whole discussion... We are proposing the following model for an issue: Basically an issue has the following properties: Id (read-only, auto-generated by the database) Description (max length of 1024 chars) Memento ViewMemento Target (see below) Priority Resolution Bounds As discussed, issues must relate to some kind of target within the specific domain model. The target interface therefore consists of a type and an id which will make each target unique and forms a foreign key for the issue to the domain object. This key is there for users of the Issue service and is not used by the service itself. The issue service provides the following methods: Add Issues Modify an issue Remove issues Get all issues Get issues by target The mementos are persisted as clobs using an implementation of XMLMemento. The process from the clients point of view will therefore be: for loading a diagram: Load diagram Query the issue service for the issues relating to the diagram (target type="x.y.z.Diagram",  target id="27") The list of related issues will then be returned. The issues can be grouped by targetId and/or targetType; or subdivided by adding properties to the memento (things like group Id or even issue Type). when the user makes changes: Modify each issue object as required Call modify Issue for each changed issue (we can possibly add a method to modify many issues?) when a diagram is imported: Import service/module can call the issues service and add the basic issues for the digram, as far as I am aware these will be label and placeholder. When it comes to a domain model that is hierarchical, it will be up to the user of the issue service to handle this. e.g: Load a diagram, get the issues for the diagram, get all the layers in the digram, For each layer get the issues for the layer get all the sub-objects in the layer, for each sub-object: get issues for the object etc... I hope this clears up the issue. I have committed the interfaces under geoserver/community/Issues. Just pull an update from trunk. Jesse, I am sure that this will mean extra work for you, my apologies. Hopefully you will come on line soon so that we can discuss it. Jody Garnett wrote: In follow up to the previous email: [11:06:25 AM] Pablo says: on wednesday when I spoke to Jesse, I was talking from the server point of view, then quinton last night spoke to him and they talked with their client classes on [11:06:32 AM] Jody Gar... says: I hope my email was not too much, please reply if you have questions. [11:07:26 AM] Pablo says: the hierarchy should not be represented in the issue, it is already represented in the domain model [11:07:41 AM] Pablo says: the client should ask for issues related to the diagram... then find all the objects within the diagram and ask for issues relating to them... and so on and so forth [11:07:56 AM] Jody Gar... says: thinking ... [11:08:01 AM] Jody Gar... says: domain model of (Diagram) [11:08:13 AM] Jody Gar... says: or domain model of Map / Layer (as per example) [11:08:37 AM] Jody Gar... says: my idea was that if there is going to be a heirarchy from the domain model, we will need target interface to tell us about it. [11:08:49 AM] Jody Gar... says: (not something the issues model can do with out being too complicated) [11:08:53 AM] Pablo says: issues does not know if domain is a hiearachy, or list or whatever [11:08:59 AM] Jody Gar... says: indeed [11:09:11 AM] Jody Gar... says: so if Map wanted to display all its issues (layers included) [11:09:21 AM] Jody Gar... says: the Map Target.getChildrenTargets() [11:09:34 AM] Jody Gar... says: would need to go through and grab all the layer targets... [11:09:34 AM] Pablo says: no [11:09:41 AM] Jody Gar... says: (that way the issuse view would not need to know anything) [11:09:59 AM] Jody Gar... says: (inanycase the final recommendation was not to do this right now ...) [11:10:02 AM] Pablo says: map.getLayers() //foreach  //getIssues(layertarget) [11:10:17 AM] Jody Gar... says: right,  and that works - if you are working with maps [11:10:27 AM] Jody Gar... says: but if we are working with Smurfs we would not know what to do. [11:10:36 AM] Jody Gar... says: (so Smurf1 would need to have a Target [11:10:49 AM] Jody Gar... says: and that Target (an interface) would need to cough up a list of child targets) [11:11:30 AM] Jody Gar... says: issue view cannot know about smurfs... [11:11:35 AM] Jody Gar... says: (not sure if I am making sense) [11:11:38 AM] Pablo says: target = "string" + "id" eg "diagram" + 27 or "layer" + 27 [11:12:58 AM] Jody Gar... says: ah, read the email [11:13:08 AM] Jody Gar... says: Target = an interface I expect us to define.... [11:13:35 AM] Pablo says: right, this is what I discussed with Jesse on wednesday [11:13:40 AM] Jody Gar... says: let me try ... [11:13:45 AM] Jody Gar... says: interface Target { [11:13:55 AM] Jody Gar... says: long getId(); // hook to issue model [11:14:13 AM] Jody Gar... says: List<Target> getChildTargets(); // usually empty [11:14:14 AM] Jody Gar... says: } [11:14:17 AM] Jody Gar... says: something like that? [11:14:35 AM] * Pablo reading email [11:14:42 AM] Jody Gar... says: cool [11:14:59 AM] Jody Gar... says: can I post this chat? [11:15:34 AM] Pablo says: sure, I'm still not untirely convinced with getCHildTargets() yet, hang on still reading email ... [11:16:00 AM] Jody Gar... says: yeah no worries, it is just an idea (more so the issue view can be general) [11:18:23 AM] Pablo says: ok, the last bit of the email was the highlight, Jesse's going to be doing a whole bunch of adapting to this [11:18:53 AM] Pablo says: let's go with, Final answer is "no" _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel