Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Dltk-dev] Re: project level task tag support added

  ok - i'll keep these things in mind as i move forward. i'm sure i'll be back w/ questions, etc as i proceed.

On Thu, Nov 6, 2008 at 12:11 PM, Alex Panchenko <alex@xxxxxxxxx> wrote:
Jae,

My concerns are about validator preferences.

There are two kind of validators now:
- single instance validator, e.g. tclchecker. Only single instance of the such validators is available (it is created when extension points are loaded) and it accesses preferences via IPreferenceStore.

- multi instance validators, e.g. ExternalChecker. They are created manually by the user. Multiple instances of these validators could be created and preferences are loaded from the XML via load(Element) and save(Element) methods of the IValidator implementation. At runtime the preferences are cached in the instances of the object implementing IValidator. When the user opens the preferences dialog editable copies of runtime configuration objects are created. After the dialog is closed by OK - the editable copies are persisted to XML and then reparsed to recreated cached runtime configuration objects.

It is possible to modify tclchecker to work with XML too, but read/write XML manually looks like waste of time in the 2008 year, and the code is hard to read/modify.

Another complex part is that some validators have paths configured for different environments. Probably it would be simpler to use separate validator configuration per each environment. So validator preferences page would look simpler and it could be reused in the project properties too - a project belongs to the single environment and dialog designed for multiple environments will look strange in this context.

So I have described some of the issues, which need to be solved. The general idea is to use EMF to avoid hand-written code to read/write preferences and implement all validators preferences in the same way.

Regards,
Alex

----- Original Message -----
From: "Jae Gangemi" <jgangemi@xxxxxxxxx>
To: "DLTK Developer Discussions" <dltk-dev@xxxxxxxxxxx>
Sent: Wednesday, November 5, 2008 10:31:14 PM GMT +06:00 Almaty, Novosibirsk
Subject: Re: [Dltk-dev] Re: project level task tag support added


alex -

i'm up for a discussion. what api are you referring to here? the validator api, or that for the project specific preferences?

i have rough working implementation of the preference/property page that is storing the preferences correctly for the project/plugin. i thought about introducing an IValidatorToolkit interface that would provide access to plugin specific values that the general validator api would require. in terms of actually running the validators, an IScriptProject is already needed to run the validators, so that would just need to be plugged into an IPreferencsLookupDelegate to grab the saved validator configurations for the project and the IValidatorToolkit implementation would provide the preference qualifier id, and all should continue to work as planned.

obviously it would be inefficent to reconstruct the validators from the preference store on each run, so some kind of caching/evicting would need to occur, but my first concern was just getting things working and optimizing later. my thoughts on how to handle this would be to store the IScriptProjects in a weak hashmap (that way if the project gets deleted, its reference in the map disappears) and use a preference change listener to evict existing entries when they change.


On Wed, Nov 5, 2008 at 11:08 AM, Alex Panchenko < alex@xxxxxxxxx > wrote:


Jae,

It's worth to have project specific validator preferences, but probably we should discuss the refactoring of the validator preferences first.
We are not quite happy with the current API and project specific preferences probably made a bit more complex to use.
What do you think?


Alex

----- Original Message -----
From: "Jae Gangemi" < jgangemi@xxxxxxxxx >
To: "DLTK Developer Discussions" < dltk-dev@xxxxxxxxxxx >



Sent: Tuesday, November 4, 2008 8:42:22 PM GMT +06:00 Almaty, Novosibirsk
Subject: Re: [Dltk-dev] Re: project level task tag support added



thanks alex!

the PythonAssistParser should be working now. i accidentally committed that change with the task tag support.

i'm looking into project specific validator preferences next. looks like i'll be a little too late for the m3 release, but hopefully it will be ready for m4.


On Tue, Nov 4, 2008 at 12:19 AM, Alex Panchenko < alex@xxxxxxxxx > wrote:


Hi Jae,

It's great you have finished it! so it will included in the M3 release on the next week.

Regarding TCL - the appropriate entries are defined by the org.eclipse.dltk.tcl.parser plugin, so I have reverted the change.

And by the way, org.eclipse.dltk.python.internal.core.codeassist.PythonAssistParser does not compile for me, would you please check?

Thanks,
Alex




----- Original Message -----
From: "Jae Gangemi" < jgangemi@xxxxxxxxx >
To: "DLTK Developer Discussions" < dltk-dev@xxxxxxxxxxx >
Sent: Monday, November 3, 2008 12:41:22 AM GMT +06:00 Almaty, Novosibirsk
Subject: [Dltk-dev] Re: project level task tag support added


hello all -

the remaining dltk plugins have been updated to support project specific tasks (and synced w/ alex's improvements). the mini howto has also been synced against the current implementation, using python as it's example.

see here: http://wiki.eclipse.org/DLTK_Adding_Todo_Task_Tag_Support

the _javascript_ plugin is still in need of a mutliline comment scanner for syntax hightlighting and locating task tags.

the tcl plugin was missing entries for the parser/task parser build participants. i am not sure if this was an oversight or not, but i have added them.


On Sat, Nov 1, 2008 at 9:23 PM, Jae Gangemi < jgangemi@xxxxxxxxx > wrote:


hello all -

after much delay, i've had a chance to finish off support for project specific task tags. support for the ruby plugin has also been added. i'll be updating the other plugins and the mini howto with the new details shortly. if you're interested in getting a jump start on this, just check out the ruby plugin for a working example.

please let me know if there are any problems and/or questions.

--
-jae



--
-jae

_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev



--
-jae

_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev



--
-jae

_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev



--
-jae

Back to the top