Home » Modeling » EMF » Why does MarkerUtil delete old markers?
|
Re: Why does MarkerUtil delete old markers? [message #547067 is a reply to message #547036] |
Thu, 15 July 2010 11:48 |
|
Hi, Subhash,
The MarkerUtil is a simple facility that was designed to support the
simple case of resource-based validation. That is, validation of an
entire resource such as might be implemented using a project builder.
In such cases, it is safe to assume that all existing markers are
obsolete because validation will find all extant problems.
If you are implementing a more incremental approach to validation, then
you will need an incremental marker management strategy. I think this
has been raised before in the newsgroup; you might try searching
Bugzilla for enhancement requests on this subject to see what others
have observed or proposed as solutions.
Cheers,
Christian
On 15/07/10 02:14 AM, Subhash Gopalakrishnan wrote:
> Hi,
>
> I am trying to understand how Markers work with the validation framework
> and I don't get why MarkerUtil explicitly deletes all existing markers
> of the same type in the file before adding on new markers corresponding
> to the ConstraintStatuses.
>
> I expect to be able to keep the old markers intact unless the
> constraints they associate with are valid now. In other words, as I
> continue editing the model in multiple steps, why would the validation
> markers from the previous step go away?
>
> It's quite possible I don't understand the way markers integrate with
> the validation framework very well. In that case, could someone point me
> to a good article or tutorial on the same?
>
> Many thanks,
> Subhash
|
|
|
Re: Why does MarkerUtil delete old markers? [message #547145 is a reply to message #547067] |
Thu, 15 July 2010 16:33 |
Ed Willink Messages: 7655 Registered: July 2009 |
Senior Member |
|
|
Hi Subhash
A number of editor projects have discovered that naive Marker update can
be very expensive; each Marker update triggers a separate server thread.
A simple recreate the content and then submit a batch update of the
differences has been used to amortise the call cost.
Regards
Ed Willink
On 15/07/2010 12:48, Christian W. Damus wrote:
> Hi, Subhash,
>
> The MarkerUtil is a simple facility that was designed to support the
> simple case of resource-based validation. That is, validation of an
> entire resource such as might be implemented using a project builder. In
> such cases, it is safe to assume that all existing markers are obsolete
> because validation will find all extant problems.
>
> If you are implementing a more incremental approach to validation, then
> you will need an incremental marker management strategy. I think this
> has been raised before in the newsgroup; you might try searching
> Bugzilla for enhancement requests on this subject to see what others
> have observed or proposed as solutions.
>
> Cheers,
>
> Christian
>
>
> On 15/07/10 02:14 AM, Subhash Gopalakrishnan wrote:
>> Hi,
>>
>> I am trying to understand how Markers work with the validation framework
>> and I don't get why MarkerUtil explicitly deletes all existing markers
>> of the same type in the file before adding on new markers corresponding
>> to the ConstraintStatuses.
>>
>> I expect to be able to keep the old markers intact unless the
>> constraints they associate with are valid now. In other words, as I
>> continue editing the model in multiple steps, why would the validation
>> markers from the previous step go away?
>>
>> It's quite possible I don't understand the way markers integrate with
>> the validation framework very well. In that case, could someone point me
>> to a good article or tutorial on the same?
>>
>> Many thanks,
>> Subhash
>
|
|
|
Re: Why does MarkerUtil delete old markers? [message #551822 is a reply to message #547036] |
Mon, 09 August 2010 16:20 |
|
Forwarding a follow-up question from e-mail channel ...
> Hi Christian,
--------8<--------
> I am working on an EMF application which, now incorporates the
> validation framework. The editing domain sets the validator factory
> with a ReadWriteValidatorImpl object, which returns a live validator,
> in my understanding. I have also added a validation listener through
> ModelValidationService API and listen to the live validations as and
> when a model object changes. The listener uses
> MarkerUtil.updateMarkers which erases all the markers and sets up only
> the latest ones.
Ah, so this application uses a TransactionalEditingDomain. That's a
detail that wasn't mentioned, earlier.
The editing domain's validator is only intended to trap and prevent
(actually, roll back) changes that would corrupt the structural
integrity of a model. They are not meant for general-purpose validation
and reporting non-fatal problems that the user can correct.
I definitely would recommend against doing anything as time- and
resource-intensive as manipulating markers in live validation. This
holds up the committing of a transaction and blocks other threads that
are trying to access the editing domain.
> My intention is to build a model editor that behaves like say, the JDT
> editor and increasingly show markers against the EMF objects that have
> problems. The markers should appear and disappear in the model tree as
> and when errors are made and corrected. I tried returning a batch
> validator from the editing domain, but I am not sure how to validate
> the entire set of model objects with that validator. Is that the right
No, you can't do that. The editing domain needs to validate
Notifications (representing model deltas), and a batch validator can't
do that.
> approach for getting what I want or is there an incremental approach
> described in a tutorial or article? I keep suspecting that this might
> be a common need for many applications but have not been able to find
> any leads in the documentation.
I would recommend a time-delayed batch validation triggered by changes
in the editor, which has nothing to do with live validation or the
editing domain (though it would need a read-only transaction, of course,
to access the model). Note that the JDT editors, for example, only
create lightweight "annotations" in the editor when validating
on-the-fly. Only the compiler actually generates problem markers, often
triggered (but not necessarily) by saving the resource.
The editors generated by Xtext implement this kind of approach
(time-delayed validation), but I think they actually do create markers.
You might have a look at how they solve this problem. Xtext doesn't
use the emf-validation component, but provides its own validator
architecture in addition to EMF's intrinsic model constraints. But
ultimately the high-level picture is similar to what you're doing.
> I really appreciate your help in this regard. Thanks so much.
I hope my reply helped.
> Subhash
|
|
|
Goto Forum:
Current Time: Sat Apr 20 03:34:50 GMT 2024
Powered by FUDForum. Page generated in 0.03092 seconds
|