On 07.09.2013 12:39, Matthias Hinz wrote: SNIP > > @Ede > I think comparing the old project location with the new project location is a > good idea, but do we really need another dialog, as the user is asked about > broken layers already? > Rather I would foster automatic behavior for more better usability.
there is the corner case of a user who only moved the *.jmp project file but left the data, although it was located below the project file before. so i would argue, moving projects happens rarely, but when they were moved, special care should be taken. so having the ok/cancel dialog at the very least points the user on what is happening behind the scenes. i don't want users erronously working with copies of data files in their od/new location, while expecting that they are modifying the other one. keep in mind, the project folder structure might have been only copied and be still existing at the old location. > I got two new Ideas on how to preserve relative location without the > downwards-compatibility problem. > They should both have same effects. I would prefer solution 2, but maybe > you'll find the first one more appealing. > > 1. Deriving possible projectfile-resource relations by comparing the old > project location with the new location: > > old location and resource: > * c:/projects/*myProject.jml > * c:/projects/*mydata/data.jml > > open project in new location: > * d:/workspace/*myProject.jml (given) > --> *d:/workspace/*mydata/data.jml (update) projects are actually *.jmp/jcs ;).. anyway. this is what i was suggesting. i don't know of jmp project files actually keep record of their respective absolute path somewhere. if not, you might have to add it. > 2. Storing relative paths in a different resource property, e.g. > "File_Relative_Location_Hint". They are used to updade the absolute path if > the project was moved or copied together with the data. > It will not affect the behavior of older version of OJ because the > absolute location are kept and the location hint-property is never evaluated. still prefer 1. above. because: - 2. adds one entry per data file, 1. only one, the project's path - it's redundant, as the relative path is already part of the data files absolute path. all we need to know is the rel. paths base folder. > > Further I'd suggest the following workflow: > > 1. Check if the project was moved; if true 2, if false 4 > 2. Try to update paths based on relative location; if resources do not exist 3 > 3. Check if resources exist denoted by the absolute path; if true update > location hint, if false 4 > 4. Ask user to select resources manually, that has not been found, if any. > (this is the feature that we already have) add the dialog to 2. and it sounds nearly perfect in any case, if a file is not found, an error arises on creating a proper path to it, 4. should pop up > > A more user-informed approach might be to prompt a table at step 4, were all > (broken) layers are listed and also the detected matching files, if any. > The user can either approve everything or choose different locations for > selected layers. I do not think that this is necessary, but possibly a > nice-to-have. agreed. up to you. > > Please let me know about your preferences. see above > I will work in parallel on the Project-Archives (*.jmz) suggested in the > user-list discussion, but keep it as a separate contribution (patch). good to know. the above outlined solution sounds like it would make a later compressed project structure readable again, with the mention warning of course. it should probably contain an additional warning, that data files are unsavable now, in case writing to zip is not implemented in the first step. ..ede > > Matthias > > [1] http://www.ohloh.net/accounts/MatthiasHinz > [2] https://github.com/MatthiasHinz > > Am 07.09.2013 00:19, schrieb edgar.sol...@web.de: >> On 06.09.2013 23:40, Stefan Steiniger wrote: >>> If you think you keep contributing the svn write access rules are as >>> follows: >>> You would have to send two code contribution/patches (one you sent >>> already). And if both are approved, then we could give you write access >>> to the SVN. Alternatively, someone else who knows already your skills >>> can speak up for you and we would give you straight write access (this >>> happened too). I think these rules are a fairly low barrier, and we are >>> always happy if someone is willing to contribute. >> i am a little reluctant to assign write access right away. let's see how the >> commitment develops. for the time being i have no problem with reviewing >> patches and committing them manually when approved. >> >> should this develop into to much trouble because of extended commitment >> it'll be easy to grant commit access and an informed decision :) >> >> wrt. to the issue.. sounds good so far. but the IndexOutOfBoundsException is >> not acceptable. i'd suggest the following workflow which i know works well >> for a software i use periodically. i know it does not use relative paths, >> but the result is quite similar. >> >> saving >> 1. keep absolute paths during saving >> 2. save the absolute path to the project file, if not already saved, as an >> extra value >> opening >> 1. compare saved project path with actual project path >> if they differ >> 1.1. open a dialog informing the user that the project has moved and offer >> to update >> a. all data file paths >> b. only data file paths for which the data is not available in it's old >> path >> >> how does that sound? i could live with only 1.1.a as well for now. but 1.1.b >> sounds like a cheap addition while were on it. >> >> nice that your tackling it :)..ede >> ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
