Re: [base] Project defaults in batch-import and experiment validator

2011-10-26 Thread Nicklas Nordborg
On 2011-10-25 19:36, Pawel Sztromwasser wrote:

 That I didn't know. So when no column mapping is provided for a
 property, the project default is used (since the property is regarded as
 not initialized, and not null). I also like the expression solution in
 column mappings. It has an advantage over a plugin parameter because it
 allows to select particular properties to apply default values to.

I have created a ticket for this: http://base.thep.lu.se/ticket/1642

/Nicklas


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
The BASE general discussion mailing list
basedb-users@lists.sourceforge.net
unsubscribe: send a mail with subject unsubscribe to
basedb-users-requ...@lists.sourceforge.net


Re: [base] Project defaults in batch-import and experiment validator

2011-10-26 Thread Nicklas Nordborg
On 2011-10-25 19:36, Pawel Sztromwasser wrote:
 I like one-click fix-it buttons (one is available for inheriting
 annotations if I am not mistaken), and they would definitely speed up
 work with BASE removing some of the repetitive interactions. If it is
 possible to include them in the roadmap for 3.1, that would be
 excellent. The sooner the better:)

And another one: http://base.thep.lu.se/ticket/1643

I put it in BASE Future release milestone since it feels like a big 
change and we already have a few big things to do in BASE 3.1

/Nicklas

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
The BASE general discussion mailing list
basedb-users@lists.sourceforge.net
unsubscribe: send a mail with subject unsubscribe to
basedb-users-requ...@lists.sourceforge.net


Re: [base] Project defaults in batch-import and experiment validator

2011-10-25 Thread Bob MacCallum
More feedback:

I've extensively used the no column-use project default
functionality, and I think it's logical to do it that way, but the
expression-based enhancement sounds like a good next step forward.

On Tue, Oct 25, 2011 at 1:01 PM, Nicklas Nordborg nick...@thep.lu.se wrote:
 On 2011-10-25 09:45, Pawel Sztromwasser wrote:
 Hello,

 I was wondering if the project defaults are used in batch importing,
 i.e. when a property is not specified in tab-delimited file but set as
 default in an active project? I did a quick test and it didn't work, so
 I thought I could suggest it. This way setting project properties
 upfront would save some work latter when editing the batch-import
 spreadsheets.
 I can imagine that in some cases it is not desired to set default
 properties automatically, so maybe a plugin configuration option to use
 project defaults would suffice. When updating with 'use defaults' option
 set, the plugin should overwrite existing properties.

 The batch importers doesn't really care about project default values.
 It is handled entirely by the core code which has a contract to set
 default values when creating new items, but only if no explicit value
 has been set.

 The key issue here is that if a column is mapped in the batch importers
 an empty value is considered as an explicit request to set the value to
 null, and the core will not use the default value. In other words, when
 using the batch importers the project default values are only used for
 unmapped columns.

 There are also a lot of changes in this area in BASE 3. It is now for
 example, possible to have more than one default value and the core tries
 to match everything depending on the subtype of an item.

 So, I don't really know what is the best solution here... Maybe, instead
 of using hard column mappings (eg. \Protocol\) we could add support
 for expressions. Something like =default() would always select the
 project default value, or =defaultIfNull('Protocol') select the mapped
 protocol if a value is specified, but uses the default if the column is
 empty.

 The second suggestion is also about the project default properties. We
 appreciate the nice and very useful links in the experiment
 overview/validator that help correct the experiment, and we saw a need
 for a new one(s). When an item is missing a protocol/software/hardware
 (or similar), the link could help in setting the default value in the
 active project. Or even suggest doing it for all the items of the same
 type having the property missing. This would be an awesome option
 allowing to fix the experiment quickly when one forgot to set the
 defaults in advance.

 The fix it links can currently only provide a link that opens an edit
 dialog. The user must do the change manually. Automatic fixes would
 really nice and could probably be done for several other problems as
 well. It is not straight-forward to implement since we'll probably have
 to keep track of a lot more information related to each suggested fix.

 Maybe we could define some kind of 'FixIt' interface and then use a
 'FixItFactory' to provide actual implementations. Seems like something
 for BASE 3.1 or later...

 /Nicklas

 --
 The demand for IT networking professionals continues to grow, and the
 demand for specialized networking skills is growing even more rapidly.
 Take a complimentary Learning@Cisco Self-Assessment and learn
 about Cisco certifications, training, and career opportunities.
 http://p.sf.net/sfu/cisco-dev2dev
 ___
 The BASE general discussion mailing list
 basedb-users@lists.sourceforge.net
 unsubscribe: send a mail with subject unsubscribe to
 basedb-users-requ...@lists.sourceforge.net


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
The BASE general discussion mailing list
basedb-users@lists.sourceforge.net
unsubscribe: send a mail with subject unsubscribe to
basedb-users-requ...@lists.sourceforge.net


Re: [base] Project defaults in batch-import and experiment validator

2011-10-25 Thread Pawel Sztromwasser

That I didn't know. So when no column mapping is provided for a 
property, the project default is used (since the property is regarded as 
not initialized, and not null). I also like the expression solution in 
column mappings. It has an advantage over a plugin parameter because it 
allows to select particular properties to apply default values to.

I like one-click fix-it buttons (one is available for inheriting 
annotations if I am not mistaken), and they would definitely speed up 
work with BASE removing some of the repetitive interactions. If it is 
possible to include them in the roadmap for 3.1, that would be 
excellent. The sooner the better:)

Pawel

On 25/10/11 16:17, Bob MacCallum wrote:
 More feedback:

 I've extensively used the no column-use project default
 functionality, and I think it's logical to do it that way, but the
 expression-based enhancement sounds like a good next step forward.

 On Tue, Oct 25, 2011 at 1:01 PM, Nicklas Nordborgnick...@thep.lu.se  wrote:
 On 2011-10-25 09:45, Pawel Sztromwasser wrote:
 Hello,

 I was wondering if the project defaults are used in batch importing,
 i.e. when a property is not specified in tab-delimited file but set as
 default in an active project? I did a quick test and it didn't work, so
 I thought I could suggest it. This way setting project properties
 upfront would save some work latter when editing the batch-import
 spreadsheets.
 I can imagine that in some cases it is not desired to set default
 properties automatically, so maybe a plugin configuration option to use
 project defaults would suffice. When updating with 'use defaults' option
 set, the plugin should overwrite existing properties.
 The batch importers doesn't really care about project default values.
 It is handled entirely by the core code which has a contract to set
 default values when creating new items, but only if no explicit value
 has been set.

 The key issue here is that if a column is mapped in the batch importers
 an empty value is considered as an explicit request to set the value to
 null, and the core will not use the default value. In other words, when
 using the batch importers the project default values are only used for
 unmapped columns.

 There are also a lot of changes in this area in BASE 3. It is now for
 example, possible to have more than one default value and the core tries
 to match everything depending on the subtype of an item.

 So, I don't really know what is the best solution here... Maybe, instead
 of using hard column mappings (eg. \Protocol\) we could add support
 for expressions. Something like =default() would always select the
 project default value, or =defaultIfNull('Protocol') select the mapped
 protocol if a value is specified, but uses the default if the column is
 empty.

 The second suggestion is also about the project default properties. We
 appreciate the nice and very useful links in the experiment
 overview/validator that help correct the experiment, and we saw a need
 for a new one(s). When an item is missing a protocol/software/hardware
 (or similar), the link could help in setting the default value in the
 active project. Or even suggest doing it for all the items of the same
 type having the property missing. This would be an awesome option
 allowing to fix the experiment quickly when one forgot to set the
 defaults in advance.
 The fix it links can currently only provide a link that opens an edit
 dialog. The user must do the change manually. Automatic fixes would
 really nice and could probably be done for several other problems as
 well. It is not straight-forward to implement since we'll probably have
 to keep track of a lot more information related to each suggested fix.

 Maybe we could define some kind of 'FixIt' interface and then use a
 'FixItFactory' to provide actual implementations. Seems like something
 for BASE 3.1 or later...

 /Nicklas

 --
 The demand for IT networking professionals continues to grow, and the
 demand for specialized networking skills is growing even more rapidly.
 Take a complimentary Learning@Cisco Self-Assessment and learn
 about Cisco certifications, training, and career opportunities.
 http://p.sf.net/sfu/cisco-dev2dev
 ___
 The BASE general discussion mailing list
 basedb-users@lists.sourceforge.net
 unsubscribe: send a mail with subject unsubscribe to
 basedb-users-requ...@lists.sourceforge.net

 --
 The demand for IT networking professionals continues to grow, and the
 demand for specialized networking skills is growing even more rapidly.
 Take a complimentary Learning@Cisco Self-Assessment and learn
 about Cisco certifications, training, and career opportunities.
 http://p.sf.net/sfu/cisco-dev2dev
 ___
 The BASE general discussion mailing list