kernowforsaxon-help

[Kernow] Namespace bindings feature added to XQuery Sandbox

[Florent G. <dar...@ya...>]

  Hi Andrew,

  I added a simple functionality, almost to discover Kernow
internals and play a little bit with it.  I added a button
"namespaces" on the XQuery Sandbox panel.  It launches a
dialogue box (designed after the ParamsDiag class) that
allow to add namespace bindings (pairs of String, prefixes
and URIs).  Bindings are saved to and loaded from the config
file.

  That permits you to add permanently bindings for prefixes
'xsl', 'fo', 'h', and the like.  I think that it could be
worth having it in a XQuery Sandbox.

  After this first look, I have a couple of remarks.  Mainly
about the configuration.  I saw Params.java uses static
members.  And I think Config.java is too monolithic and
rather big and could be break down within a few classes.

  For example for the namespace bindings, I add a new class
NamespaceBindings whose the only responsablity is to act as
a container for bindings.  You can then store it in the
configuration, and pass it to the dialog box.  The dialog
box then never use the config singleton, so it is easier to
reuse it later.

  Unfortunately, NetBeans changed a lot of files, mainly
project and build related.  It changed also generated code
in TabbedView.java and TabbedView.form.  So I'm not sure
they are suitable to commit.  You can instead find a patch
and the new files there:

    http://www.fgeorges.org/tmp/kernow.diff
    http://www.fgeorges.org/tmp/kernow-simple.diff
    http://www.fgeorges.org/tmp/NamespaceBindings.java
    http://www.fgeorges.org/tmp/NamespacesDiag.form
    http://www.fgeorges.org/tmp/NamespacesDiag.java

  kernow-simple.diff is a simplification of the patch, with
only relevant part in Java sources (that is, without
administrative files, TabbedView.form, and without some part
in generated code in TabbedView.java).

  Is that in accord with the way you are developing Kernow?

  Regards,

--drkm



















      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 

Re: [Kernow] Namespace bindings feature added to XQuery Sandbox

[Andrew W. <and...@gm...>]

>   I added a simple functionality, almost to discover Kernow
> internals and play a little bit with it.  I added a button
> "namespaces" on the XQuery Sandbox panel.  It launches a
> dialogue box (designed after the ParamsDiag class) that
> allow to add namespace bindings (pairs of String, prefixes
> and URIs).  Bindings are saved to and loaded from the config
> file.
>
>   That permits you to add permanently bindings for prefixes
> 'xsl', 'fo', 'h', and the like.  I think that it could be
> worth having it in a XQuery Sandbox.

The XQuery Sandbox was added just as a way to play with XQuery.  Good
idea though (and a good choice of a discrete package of work).


>   After this first look, I have a couple of remarks.  Mainly
> about the configuration.  I saw Params.java uses static
> members.  And I think Config.java is too monolithic and
> rather big and could be break down within a few classes.

The Config class maintains the state for Kernow, and as such its
pretty big.  In this case though its not needed.  If you want to store
the namespaces in the Properties file, just write  Save and Load
methods in NamespaceBindings (called from TabbedView on load and
close) that uses the static PropertyManager.

>   For example for the namespace bindings, I add a new class
> NamespaceBindings whose the only responsablity is to act as
> a container for bindings.  You can then store it in the
> configuration, and pass it to the dialog box.  The dialog
> box then never use the config singleton, so it is easier to
> reuse it later.

Yes, I think it should work in exactly the same way as ParamsDiag and Params.

>   Unfortunately, NetBeans changed a lot of files, mainly
> project and build related.  It changed also generated code
> in TabbedView.java and TabbedView.form.  So I'm not sure
> they are suitable to commit.  You can instead find a patch
> and the new files there:
>
>     http://www.fgeorges.org/tmp/kernow.diff
>     http://www.fgeorges.org/tmp/kernow-simple.diff
>     http://www.fgeorges.org/tmp/NamespaceBindings.java
>     http://www.fgeorges.org/tmp/NamespacesDiag.form
>     http://www.fgeorges.org/tmp/NamespacesDiag.java
[snip]
>   Is that in accord with the way you are developing Kernow?


Yes, I think that's a good start.  Some things that needs fixing first though:

- The buttons on the NamespacesDiag still say "Add Param" and "Delete Param"

- The variable names in NamespacesDiag are still the same as in
ParamsDiag (eg paramsTable) they should really be renamed

- NamespaceBindings should be static, as should the "myBindings" Map
(just like Params)

- There aren't any comments, or JUnit tests.  Ideally the code you
submit should be reasonably documented and at least have a few JUnit
tests (I know my code isn't exactly well documented or tested, but
these things become really important when there's more than 1
developer).

I couldn't comment on the changes to TabbedView, or on
StandaloneXQuery if you've made any changes there.

cheers
andrew

-- 
http://andrewjwelch.com

Re: [Kernow] Namespace bindings feature added to XQuery Sandbox

[Florent G. <dar...@ya...>]

Andrew Welch wrote:

> Good idea though (and a good choice of a discrete package
> of work).

  I'll try to write a little bit about that.  The form is
really simple, as well as the business code, and it deals
with saving/loading properties.  So if someone else wants to
help, that could be an interesting entry point.

> The Config class maintains the state for Kernow, and as
> such its pretty big.  In this case though its not needed.
> If you want to store the namespaces in the Properties
> file, just write Save and Load methods in
> NamespaceBindings (called from TabbedView on load and
> close) that uses the static PropertyManager.

  Ok, I'll change that.

> - The buttons on the NamespacesDiag still say "Add Param"
> and "Delete Param"

  Ok.

> - The variable names in NamespacesDiag are still the same
> as in ParamsDiag (eg paramsTable) they should really be
> renamed

  Yes.  That was the first time I used the NetBeans GUI
designer (and I must admit the first time I designed a GUI).
I'm not used to check little details in the property dialog
box nor to check the generated code.

> - NamespaceBindings should be static, as should the
> "myBindings" Map (just like Params)

  Actually, I went that way on purpose.  I'm really not
convinced that using static with a semantics of singleton is
a good thing.  If I correctly understand, this class is
static because we only need one *at this time* and that
seems easier to access its members through static access
than to pass an instance to each place that needs to use it.

  To take another example, I'd like to add another feature
on the XQuery Sandox, a dialog box to define variables, the
same way ParamsDiag define parameters for XSLT.  What would
be great should be to be able to reuse the ParamsDiag GUI
piece here.  That is not an OO-integrist approach, as it
would be worth adding facilities on this dialog box to
define variables of special types (file paths with a
graphical navigator for instance).

  That is unfortunately not possible, as ParamsDiag uses
directly Params.  I think this is contrary to the MVC
paradigm.  What I think could be maybe more flexible should
be having a VariableBindings interface.  This interface will
be implemented by Params, and by the model behind the XQuery
Sandbox.  And the ParamsDiag will be constructed with an
object that implements this interface.  So instead of:

    ParamsDiag --use--> Params

you would have (ParamsDiag's constructor will require a
VariableBindings):

    ParamsDiag --use--> VariableBindings
                           |
                           +--impl--> Params
                           +--impl--> XQuerySandboxVariables

  (Maybe VariableBindings could be a concrete class instead that only
stores and permits to retrieve variable/param definitions, as
NamespaceBindings is.)

  I think this is very important for flexibility and to
reduce dependencies in Kernow's code.  What do you think?

> - There aren't any comments, or JUnit tests.  Ideally the
> code you submit should be reasonably documented and at
> least have a few JUnit tests (I know my code isn't exactly
> well documented or tested, but these things become really
> important when there's more than 1 developer).

  Yes off course.  That was just a first draft and I just
wanted to be sure that I was "on the right way" before
spending time in documentation and testing.

> I couldn't comment on the changes to TabbedView, or on
> StandaloneXQuery if you've made any changes there.

  They are contained in the following patch (the simple one
is the same without difference mainly generated by
NetBeans):

    http://www.fgeorges.org/tmp/kernow.diff
    http://www.fgeorges.org/tmp/kernow-simple.diff

  I'll integrate your change this evening, once at home.

  Regards,

--drkm





















	
		
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com

Re: [Kernow] Namespace bindings feature added to XQuery Sandbox

[Andrew W. <and...@gm...>]

On 6/27/07, Florent Georges <dar...@ya...> wrote:
> > - NamespaceBindings should be static, as should the
> > "myBindings" Map (just like Params)
>
>   Actually, I went that way on purpose.  I'm really not
> convinced that using static with a semantics of singleton is
> a good thing.  If I correctly understand, this class is
> static because we only need one *at this time* and that
> seems easier to access its members through static access
> than to pass an instance to each place that needs to use it.
>
>   To take another example, I'd like to add another feature
> on the XQuery Sandox, a dialog box to define variables, the
> same way ParamsDiag define parameters for XSLT.  What would
> be great should be to be able to reuse the ParamsDiag GUI
> piece here.  That is not an OO-integrist approach, as it
> would be worth adding facilities on this dialog box to
> define variables of special types (file paths with a
> graphical navigator for instance).
>
>   That is unfortunately not possible, as ParamsDiag uses
> directly Params.  I think this is contrary to the MVC
> paradigm.  What I think could be maybe more flexible should
> be having a VariableBindings interface.  This interface will
> be implemented by Params, and by the model behind the XQuery
> Sandbox.  And the ParamsDiag will be constructed with an
> object that implements this interface.  So instead of:
>
>     ParamsDiag --use--> Params
>
> you would have (ParamsDiag's constructor will require a
> VariableBindings):
>
>     ParamsDiag --use--> VariableBindings
>                            |
>                            +--impl--> Params
>                            +--impl--> XQuerySandboxVariables
>
>   (Maybe VariableBindings could be a concrete class instead that only
> stores and permits to retrieve variable/param definitions, as
> NamespaceBindings is.)
>
>   I think this is very important for flexibility and to
> reduce dependencies in Kernow's code.  What do you think?

Ok, I think it sounds like a good idea, and reducing dependencies is
always good.  However you could just reuse Params + ParamsDiag for the
XQuery Sandbox parameters.  Its just a HashMap of name/value pairs
stored in Map using the URI of the stylesheet as the key - you could
just use it without modification (just use say "XQuerySandbox" as the
key)- its already shared between transform parameters and Ant
parameters....

I agree through that it could do with refactoring to be better
separated, so if you want to do it that would be great.

-- 
http://andrewjwelch.com

Re: [Kernow] Commit procedure (was: Namespace bindings feature added to XQuery Sandbox)

[Florent G. <dar...@ya...>]

Andrew Welch wrote:

  Hi

> I agree through that it could do with refactoring to be better
> separated, so if you want to do it that would be great.

  That would be interesting, yes.  But before doing any more work, I
wonder if we can agree on a commit procedure.  As you can see with the
differences between the two following patches:

    http://www.fgeorges.org/tmp/kernow.diff
    http://www.fgeorges.org/tmp/kernow-simple.diff

NetBeans changes a lot of files even for quite little changes in the
code.  Manly in administrative files (project files and so on) and
*.form files.

  Maybe I could first try to commit the namespace feature on the XQuery
Sandbox (once finished & tested), and then you will be able to see if
all remains OK for you after having updated the project?

  Maybe it would be better to use exactly the same NetBeans setup as
yours to minimize those noisy changes?  I use NB 6.0 M9 (that's the
latest milestone, and I'm surprised to see that *.form files here have
/Form/@version eq '1.3' while you have '1.4').  What are you using? 
Any specific module?

  When we arrive at a solution, maybe it could be interesting to
activate the Wiki on the project, to keep track of this info.  I think
Wikis are perfect for this kind of info.  What do you think?

  Regards,

--drkm





















      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 

Re: [Kernow] Commit procedure (was: Namespace bindings feature added to XQuery Sandbox)

[Andrew W. <and...@gm...>]

On 6/27/07, Florent Georges <dar...@ya...> wrote:
> Andrew Welch wrote:
>
>   Hi
>
> > I agree through that it could do with refactoring to be better
> > separated, so if you want to do it that would be great.
>
>   That would be interesting, yes.  But before doing any more work, I
> wonder if we can agree on a commit procedure.  As you can see with the
> differences between the two following patches:
>
>     http://www.fgeorges.org/tmp/kernow.diff
>     http://www.fgeorges.org/tmp/kernow-simple.diff
>
> NetBeans changes a lot of files even for quite little changes in the
> code.  Manly in administrative files (project files and so on) and
> *.form files.


Please don't commit any files in the nbproject directory, but do
commit all the .form files.

>   Maybe I could first try to commit the namespace feature on the XQuery
> Sandbox (once finished & tested), and then you will be able to see if
> all remains OK for you after having updated the project?

Sure.  I'll add you to the project now.

>   Maybe it would be better to use exactly the same NetBeans setup as
> yours to minimize those noisy changes?  I use NB 6.0 M9 (that's the
> latest milestone, and I'm surprised to see that *.form files here have
> /Form/@version eq '1.3' while you have '1.4').  What are you using?
> Any specific module?

Its the GUI Builder Update (iirc) from the "Netbeans Update Center
Beta" under "Tools / Update Center".  I use Netbeans 5.5.1 - I think
its still a bit too early NB 6.0.

>   When we arrive at a solution, maybe it could be interesting to
> activate the Wiki on the project, to keep track of this info.  I think
> Wikis are perfect for this kind of info.  What do you think?

Ok, I'll enable it.

-- 
http://andrewjwelch.com

Re: [Kernow] Commit procedure (was: Namespace bindings feature added to XQuery Sandbox)

[Florent G. <dar...@ya...>]

Andrew Welch wrote:

> On 6/27/07, Florent Georges wrote:

  Hi

> >   Maybe I could first try to commit the namespace
> > feature on the XQuery Sandbox (once finished & tested),
> > and then you will be able to see if all remains OK for
> > you after having updated the project?

> Sure.  I'll add you to the project now.

  I've just commited it.  Could you please update your copy
and test if all seems ok?

> >   Maybe it would be better to use exactly the same
> > NetBeans setup as yours to minimize those noisy changes?

> Its the GUI Builder Update (iirc) from the "Netbeans
> Update Center Beta" under "Tools / Update Center".  I use
> Netbeans 5.5.1

  Ok.  I remade all changes on a fresh copy after having
installed NB 5.5.1 and updated Matisse (aka GUI Builder).
The changes in administrative and generated files are far
less important than with NB 6.0M9.

> >   When we arrive at a solution, maybe it could be
> > interesting to activate the Wiki on the project, to keep
> > track of this info.  I think Wikis are perfect for this
> > kind of info.  What do you think?

> Ok, I'll enable it.

  I'll try to see this weekend if I can add a few words on
the way I added this functionality, the responsabilities of
the classes I modified and/or the setup of the tools & IDE.

  BTW, I saw you still used JUnit 3.  By habit I used JUnit
4.  Is there any reason to use JUnit while we are using Java
SE 6?  I can revert back my unit tests to JUnit 3 if needed.

  Regards,

--drkm




















      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 

Re: [Kernow] Commit procedure (was: Namespace bindings feature added to XQuery Sandbox)

[Andrew W. <and...@gm...>]

On 6/29/07, Florent Georges <dar...@ya...> wrote:
>   I've just commited it.  Could you please update your copy
> and test if all seems ok?

Great, I'm just looking at it now.

>   BTW, I saw you still used JUnit 3.  By habit I used JUnit
> 4.  Is there any reason to use JUnit while we are using Java
> SE 6?  I can revert back my unit tests to JUnit 3 if needed.

I've not used JUnit, and it doesn't seem to play well with Netbeans
5.5.1.  In order to run the test class NamespaceBindingsTest, I had to
replace the JUnit jar that shipped with Netbeans with the latest
version, add it to the Test classpath, and then modify the test itself
to extend TestCase so that the GUI would run the tests.

Then tests like this fail because they lack the assert statement:

    @Test( expected = IllegalArgumentException.class )
    public void testAddBindingPrefixBound()
    {
        NamespaceBindings b = new NamespaceBindings();
        b.addBinding("prefix", "uri");
        b.addBinding("prefix", "uri");
        fail("addBinding() should have threw an IllegalArgumentException.");
    }

Personally I would prefer to stick with JUnit 3.5.1 while Netbeans
5.5.1 is the chosen IDE for Kernow development.  I can't see any
compelling reason to go JUnit 4 just yet, and lots of reasons to stick
with 3.5.1.

-- 
http://andrewjwelch.com

Re: [Kernow] Commit procedure

[Florent G. <dar...@ya...>]

Andrew Welch wrote:

> On 6/29/07, Florent Georges wrote:

  Hi

> >   BTW, I saw you still used JUnit 3.  By habit I used JUnit
> > 4.  Is there any reason to use JUnit while we are using Java
> > SE 6?  I can revert back my unit tests to JUnit 3 if needed.

> I've not used JUnit, and it doesn't seem to play well with
> Netbeans 5.5.1.  In order to run the test class
> NamespaceBindingsTest, I had to replace the JUnit jar that
> shipped with Netbeans with the latest version, add it to
> the Test classpath, and then modify the test itself to
> extend TestCase so that the GUI would run the tests.

  Mmh, that seems a lot of manipulations...  What I did is
simply open the project properties, "Libraries", "Compile
Tests" tab: remove the JUnit 3 library and add a new JUnit 4
library.

  And that's it.  Right click "Run File" or "Shift+F6" and
NetBeans executes correctly the tests and display the
results (all tests pass).

> Then tests like this fail because they lack the assert
> statement:

>     @Test( expected = IllegalArgumentException.class )
>     public void testAddBindingPrefixBound()
>     {

  It seems that you still use JUnit 3 then (if the
annotation is not taken into account and if you had to make
the class extend TestCase.

> Personally I would prefer to stick with JUnit 3.5.1 while
> Netbeans 5.5.1 is the chosen IDE for Kernow development.
> I can't see any compelling reason to go JUnit 4 just yet,
> and lots of reasons to stick with 3.5.1.

  I find personally JUnit 4 more easy to use, more clear, in
particular regarding the exception handling testing.  But if
you confirm you prefer to remain to JUnit 3, I'll change the
unit test of course.

  Regards,

--drkm



















      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 

Re: [Kernow] Commit procedure

[Andrew W. <and...@gm...>]

On 7/2/07, Florent Georges <dar...@ya...> wrote:
> > I've not used JUnit, and it doesn't seem to play well with
> > Netbeans 5.5.1.  In order to run the test class
> > NamespaceBindingsTest, I had to replace the JUnit jar that
> > shipped with Netbeans with the latest version, add it to
> > the Test classpath, and then modify the test itself to
> > extend TestCase so that the GUI would run the tests.
>
>   Mmh, that seems a lot of manipulations...  What I did is
> simply open the project properties, "Libraries", "Compile
> Tests" tab: remove the JUnit 3 library and add a new JUnit 4
> library.
>
>   And that's it.  Right click "Run File" or "Shift+F6" and
> NetBeans executes correctly the tests and display the
> results (all tests pass).

Interesting, my version of Netbeans steadfastly refuses to run it
unless it extends TestCase - are you running a clean install of 5.5.1?

> > Personally I would prefer to stick with JUnit 3.5.1 while
> > Netbeans 5.5.1 is the chosen IDE for Kernow development.
> > I can't see any compelling reason to go JUnit 4 just yet,
> > and lots of reasons to stick with 3.5.1.
>
>   I find personally JUnit 4 more easy to use, more clear, in
> particular regarding the exception handling testing.  But if
> you confirm you prefer to remain to JUnit 3, I'll change the
> unit test of course.

Whether assertions make the code cleaner or not is up for debate... :)

I think it's best to stick with JUnit 3 for now, and switch to 4 when
Netbeans supports it out of the box.

-- 
http://andrewjwelch.com

Re: [Kernow] Commit procedure

[Florent G. <dar...@ya...>]

Andrew Welch wrote:

> I think it's best to stick with JUnit 3 for now

  Commited.  Could you please update your copy and run it under your
NetBeans, to be sure all is ok regarding the setup?

  Regards,

--drkm






















	

	
		
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com

Re: [Kernow] Commit procedure

[Andrew W. <and...@gm...>]

On 7/2/07, Florent Georges <dar...@ya...> wrote:
>   Commited.  Could you please update your copy and run it under your
> NetBeans, to be sure all is ok regarding the setup?

Yes - all fine now.


-- 
http://andrewjwelch.com