lexi-developer — Lexi developer mailing list

[Lexi-developer] Lexi 0.2 testers needed

[Stephen C. <cr...@ds...>]

Folks,

I'm getting ready to "roll" the Lexi 0.2 release.  I need to create a 
"release note" that lists the
changes and update the "build.xml" file to generate the distribution 
tarball and zipfile.

When that's done, I'd like a couple of people to do a quick sanity check 
on the distro
files before they are made available for general download.

Volunteers please ...

-- Steve

[Lexi-developer] Re: Why do lexi editors read/write files asynchronously?

[<gu...@ir...>]

	Hi guys,

	How are you? Well... I'm sorry but I have no good explanation! Maybe it=20
was just for not blocking the editor during reading/writing long files?

	I believe nothing won't break too much if you remove this extra layer=20
of complexity :-)

	Let me know!
	Yann

Stephen Crawley a =E9crit :
> Hi Yann-Ga=EBl,
>=20
> Perhaps you could explain something about the Lexi editor classes for m=
e?
>=20
> The insert, append, read and write methods of the RFTEditor class all u=
se
> a separate thread to read from or write to a file.  The same code appea=
rs
> in the other Editor subclasses.
>=20
> Why do they do this rather than reading / writing files synchronously? =
=20
> Would
> it break anything if I removed this complexity?
>=20
> -- Steve

--=20
Yann-Ga=EBl Gu=E9h=E9neuc, Ph.D.
Professeur adjoint / Assistant professor
GEODES - Group of Open and Distributed Systems,
          Experimental Software Engineering
DIRO, Universit=E9 de Montr=E9al         1-514-343-6782 (T=E9l=E9phone / =
Phone)
C.P. 6128, succursale Centre-Ville   1-514-343-5834 (T=E9l=E9copie / Fax)
Montr=E9al, QC, H3C 3J7, Canada        www.yann-gael.gueheneuc.net/Work/

[Lexi-developer] Why do lexi editors read/write files asynchronously?

[Stephen C. <cr...@ds...>]

Hi Yann-Ga=EBl,

Perhaps you could explain something about the Lexi editor classes for me?

The insert, append, read and write methods of the RFTEditor class all use
a separate thread to read from or write to a file.  The same code appears
in the other Editor subclasses.

Why do they do this rather than reading / writing files synchronously? =20
Would
it break anything if I removed this complexity?

-- Steve

[Lexi-developer] The "build.sh" script should die.

[Stephen C. <cr...@ds...>]

Mark,

I think the "build.sh" script should be killed, along with the JAR files 
that it uses.  On examination, it
turns out to be just an ancient copy of Apache Ant: it says "Ant version 
1.1 compiled on July 18 2000".
This version doesn't support many modern Ant tasks such as the "copy" task.

If we do this, we will need to document that Lexi requires a recent copy 
of Ant to compile.  But this
is no great problem.  Fedora Core 4 includes a modern Ant, and Eclipse 
has builtin Ant support.

If we don't do this, I will need to back out my last change to the 
"build.xml" file.

What do you think?

-- Steve

[Lexi-developer] Problems with the Registry class

[Stephen C. <cr...@ds...>]

Hi Mark,

In reformatting the class, I've come to the conclusion that there are a 
number of things about it
that are "broken".  I'd like your opinion on my diagnosis / suggestions.

The Registry class is the basis for Lexi's user preferences / properties 
support.  [In fact, it looks
like the original author had significantly bigger plans.]  The model for 
the Registry is as follows:

  *  A Registry contains properties that are triples consisting of a 
name, a value and a type.

  *  Property types consist of Java primitive types, String and Object, 
and arrays of the previous.

  *  Properties are organised as groups so that a Registry property is 
denoted by the property name and
     the group name.

The Registry class seems to be designed  to allow multiple 
implementations of the abstraction, except
that this has been done wrongly IMO.  The javadoc says that you should 
use static "loadXXX" methods
to instantiate a Registry.  These methods create instances of the 
Registry.Impl inner class, which
is a subclass of Registry.  [A bit unusual ...]  The problem is that:

  1)  the Registry class is non-abstract and has a protected 
constructor, and

  2)  the non-static methods of the Registry class are (mostly) 
skeletons which don't do what
      the javadoc says they should do.

So Registry is not a safe class.  If a client creates an instance of 
Registry via the constructor, it gets
a non-functional object.  And it is dangerous as a superclass for a real 
implementation (like the Impl class)
because it contributes disfunctional method implementation.

IMO, the fix is to turn Registry into an abstract class, and make the 
Impl class a non-nested class with
package private access.

Another problem is that it is (IMO) sloppy about the typing of properties:

  1)  Nothing stops an application setting a property with (say) a 
String value when it was previously
      (say) an array of ints.

  2)  If an application tries to get a property with the wrong type, it 
will get a default value.

  3)  If the application uses the referenceGroup, it gets the properties 
in a group as a Properties
      object with the type encoded in the property values.  If the 
Properties object is updated (as
      the PropertySheetDialog class does!), the updates are reflected in 
the registry ... without
      any checking that the registry type prefix makes sense.

IMO, the fix to these problems is to rework the getters and setters, and 
to get rid of the referenceGroup
method.  The getters and setters need to throw an (unchecked I think) 
exception if the application gets
the types wrong.  And we need a better way of setting initial values 
than the current kludge of using
the default value supplied in a getter as an initial value whan the 
property is missing.

What do you reckon?

-- Steve