ginp-developers

[Ginp-developers] Char Encodings.

[Doug C. <d.c...@na...>]

Dear Justin,

I have changed all refs for ISO encodings to UTF-8.  This is because I 
now understand the UTF-8 encoding after RTFM.  I do not think this is a 
problem for the XML files because they are all ASCII.  The Char Map plug 
in in jEdit is missleading as it does not display UTF-8 correctly.  I 
will try to get some translation stuff done.  This is not much work at 
the moment because there is not a lot of text in the files.  This will 
help us expand our potential user base, and it is fun.

I had a fresh look at how to do a database based application and again 
there is some very interesting work going on in the FOSS world.  I had a 
look at turbine from apache and it looks like a good place to start.  I 
think it is worth making the ginp use a database independent layer if we 
can.  I would have to start the db application stuff from scratch so 
using turbine or hibernate is less rather than more work in the short 
and long term.  In the passed I have had an XML database definition 
which I used to auto generate data entry forms.  Each data type is an 
object etc...  I think this is fairly standard.  Special forms can be 
done with taglibs ad custom JSP pages, but most data entry stuff is 
handled with the standard auto generated forms and search facilities.  I 
am sure you have your own ideas about how to do this so please give me a 
brain dump and project names so that I can RTFM, and we can progress 
this together. 

If you are doing documentation of how the application works (or will 
work) maybe you could add it to the docs/ or Notes.txt so we can publish 
it with the project.  I am sure that this material will be useful to 
developers trying to understand how the application works so that they 
can customize it.

As for the bugs in the perfs interface I have no idea how to solve 
this.  I would say that the wizard writes the ginp.xml file into the 
WEB-INF folder.  Therefore If there is a file there use it if not then 
it need to run the config wizard.  This hard codes the config file which 
is not great but I have no other bad ideas at the moment.  It is however 
an easy thing for me, ginp users and the java virtual machine to understand.
 
I have a Skype (internet telephone) account.  I am dougculnane.  If 
needed we could try this to discuss stuff.  However the chat thing 
worked very well, so maybe this is the best facility.

Happy Hols,
 
Doug

-- 
Douglas Culnane BEng.    
NaviDat Software         
Sechshauserstrasse 83    
1150 Wien, Austria       
Tel: ++43 1 897 25 00 36 
Fax: ++43 1 897 25 00 21 
d.c...@na...    
www.navidat.com          

Re: [Ginp-developers] Char Encodings.

[Justin <ju...@sq...>]

Doug,

	I strongly recommend we use Hibernate.  I have spent a lot of time 
working with it professionaly and have found it a joy to work with and 
is practically the de-facto standard for open source java these days and 
it is very database independent.    Turbine to my knowledge uses OJB 
which is a much less popular framework.
	I thought using Tapestry for the setup application went really 
smoothly.  Tapestry makes some things very very easy.  For instance if 
you have a list of 100 images, each having their own options such as 
name or width/height whatever tapestry lets you submit changes to all 
those image parameters with one form submit.  With JSP/Servlets you have 
to handle all the encoding of array suffixes,etc in the form parmaeters 
yourself.  If you want to learn Tapestry you should get Manning's 
Tapestry in Action.  The online docs are a little wanting.
	Also, I wnat to improve the thumbnail generation process. If I have a 
big directory of pictures, the first time I load it the whole thing is 
full of broken images and I'm thinking to myself that this is a bug as 
will most first time users.  I know that ginp is building thumbs in the 
background but I think the better way to do this is to build in the 
background and notify each thread trying to load a picture when the 
image is done building (using wait()/notify()) so things load slowly but 
they all load the first time someone hits the directory.
	I think we can leave the prefs interface alone.  The .ginp file in the 
home directory is the only way we can keep people from having to open up 
the war which imho is a good thing.  If we hear users complaining I can 
switch to the .ginp file.  Now having thought about it I think resin 
2.1.8 is pretty old (they're on the 3.0 series now) and most open source 
projects like JRoller don't work on it anyway.

Regards,

	Justin
	
	

Doug Culnane wrote:

> I think this is fairly standard.  Special forms can be 
> done with taglibs ad custom JSP pages, but most data entry stuff is 
> handled with the standard auto generated forms and search facilities.  I 
> am sure you have your own ideas about how to do this so please give me a 
> brain dump and project names so that I can RTFM, and we can progress 
> this together.
> If you are doing documentation of how the application works (or will 
> work) maybe you could add it to the docs/ or Notes.txt so we can publish 
> it with the project.  I am sure that this material will be useful to 
> developers trying to understand how the application works so that they 
> can customize it.
> 
> As for the bugs in the perfs interface I have no idea how to solve 
> this.  I would say that the wizard writes the ginp.xml file into the 
> WEB-INF folder.  Therefore If there is a file there use it if not then 
> it need to run the config wizard.  This hard codes the config file which 
> is not great but I have no other bad ideas at the moment.  It is however 
> an easy thing for me, ginp users and the java virtual machine to 
> understand.
> 
> I have a Skype (internet telephone) account.  I am dougculnane.  If 
> needed we could try this to discuss stuff.  However the chat thing 
> worked very well, so maybe this is the best facility.
> 
> Happy Hols,
> 
> Doug
> 

Re: [Ginp-developers] Char Encodings.

[Justin <ju...@sq...>]

Doug,

	Here's a pretty good article on The Server Side (a popular java news 
forum) about switching to Tapestry... Pretty much positive.  Basically, 
it's a paradigm shift but it's worth it.  A lot of people seem to be 
wondering about their switch to JDO and how it lacks vs. Hibernate though.

http://www.theserverside.com/news/thread.tss?thread_id=31313

I know you were interested in letting people customize the look and feel 
so I thought you might find the following interesting:

<i>

The big effect of using Tapestry (and also XMLC btw) for us has been 
that it allows our web designers to be integral in the whole UI design 
process. Real separation of concerns.

Tapestry and XMLC pages are *plain* HTML. With a jsp page, it becomes 
much more difficult to maintain the page visually. The jsp stuff gets in 
the way of the HTML designer, whereas for the developer the HTML is just 
something to be tolerated. And you *really* dont want a coder handling 
the visuals. It is definitely a different skill from coding.

It may be *possible* to do it all in JSP, but is it *easy*? That greatly 
affects maintainability, error counts, etc.

Kit

</i>

I think you can move the tapestry files out of the classpath in the 
latest version 3.1.

Regards,

	Justin