>> 3. Many supertypes will be abstract and will rely on an implementing >> subtype declaring a concrete implementation. >> >> So - we need to bind attribute declarations to java objects in a lazy >> way - and throw an informative error if an attribute cannot be bound to >> a java class. >> > This hits on a key issue, one of validation. A lot of code in the old > models dies when you try to do this, set an attribute value which does > not match its binding. Jody has put it well many times, the need to have > "bad data" around. I think validation should be something the occurs > when it is asked for, like when data is being sent to a datastore or > something... > Ah - you are one further step ahead here - what to do when binding data to the feature type - I was thinking as far ahead as constructing the internal model.
If we wanted to carry "bad" data around, we may need an "original unparsed object" saved, this shouldnt be too hard -but will it cause an API issue? generally, the parsed objects should be saved I guess. What happens when there is content in the submitted feature that doesnt match the feature type? Also, validation may be on the content rather than the parseability. You are right, validation may be quite expensive, and may also only be of interest when persisting or serialising (which may require binding to a different model). Is there any published pictures of the internal architecture in this respect? Rob >> we should have default bindings, plug-in defined additional bindings >> and mapping-controlled bindings to cope. Default (what geoserver does) >> and mapping-controlled bindings the priority. >> >> Rob >> >>>> Gabriel >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> Take Surveys. Earn Cash. Influence the Future of IT >>>> Join SourceForge.net's Techsay panel and you'll get the chance to share >>>> your >>>> opinions on IT & business topics through brief surveys-and earn cash >>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>>> _______________________________________________ >>>> Geotools-devel mailing list >>>> Geotools-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Geotools-devel mailing list >> Geotools-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >> !DSPAM:1004,45e5fa0d269991665516417! >> >> > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
