edocs-development Mailing List for edocs (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi,

Here are eDocs logo proposals, tell me what you think.

Piotr

Derek,=20

remember that for this first phase is appreciate (required could be =
better) only integration with Office 2000/XP and Windows explorer. =
Forget other products for the moment. We'll approach that problem in a =
next release.

Sergio
Some of you have been assigned of some task. You can review that going to
the project web site. Other tasks are not assigned so you're free to offer
yourself as volonteers to complete it. Possibly keep task status properly
updated.

Pls let me know if someone cannot complete for the time required or cannot
do the assigned task at all. Remember the all the documentation needs to
have the official format of the vision and requirements docs.

Again remember that, until now and based on the effort everyone has given to
the project,  staff is organized in that way

Piotr Kreglicki - head for the application web front-end design and
development project web site management
Derek Harmon - head for the development of integration modules (client and
server side) using web service technologies
Ashwini Kumar - head for development of storage and search engine module

Everyone who want to work, or that already works, in those areas needs to
coordinate with them for every activity. Also everyone of them has the
authority to open and assign tasks to everyone they're working with in their
respective areas. Ashwini remember to quickly give me your sourcefoge nick
pls.

The commits mailing list has been activated, so, subscribe to it
(edo...@li...) if you want to trace what happens in
the repository (the subscription is not required but suggested)

Piotr, have you done with the news script to publish the project news on the
web site?

Regards

Sergio

Derek,

can you interact with Piotr? Piotr, I've inserted a news that state that our
web site is online.

Try it

Sergio
----- Original Message -----
From: "Piotr Kreglicki" <pkr...@wp...>
To: "edocs-development mailing" <edo...@li...>
Sent: Wednesday, October 09, 2002 7:54 PM
Subject: Re: [Edocs-development] Integration of the news with website

> Sergio Ramazzina wrote:
>
> > Great as usual Piotr,
>
> Thank you.
>
> > I've tried the site functionalities and works great. I'll add news to
the
> > project
> > immediately. I was waiting for your ok to let the site be annouced. I've
you
> > solved
> > the problem with publishing the site news? At the moment we've not many
news
> > but I suppose we'll got many soon. Is it possible to have the an excerpt
of
> > the latest
> > news on the home page of the web site?
> >
> > I've tried also the two different resolutions and are ok.
> >
> > The script you're talking in your email related to news publish or to
> > resolution adjustment?
>
> It's for the news. It works that way: a perl script is being run
> according to cron schedule. It's connecting to project news database and
> checks if there's something new. Then it creates a html file with the
> news. I wanted you to post some news to see it in action, what this
> created file looks like and so on. And then I'll integrate it with the
> website.
>
> > Derek can you write some text to put in the web site to illustrate our
> > integration
> > capabilities? Can you coordinate that with Piotr? Integration is a good
> > point for
> > a system like that. Piotr I think that we need to find a little space
for
> > that on the site.
> > I was thinking the same more or less we have done for Vision, Benefit,
and
> > What is.
>
> Yes, of course, when I get the text I'll put it online. But I hope it
> won't be too big. I think it would be good to make a brief overview of
> the integration capabilities (just main features) for the front page and
> bigger, more detailed document for download.
>
> Regards
> Piotr
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Edocs-development mailing list
> Edo...@li...
> https://lists.sourceforge.net/lists/listinfo/edocs-development

Sergio Ramazzina wrote:

> Great as usual Piotr,

Thank you.

> I've tried the site functionalities and works great. I'll add news to the
> project
> immediately. I was waiting for your ok to let the site be annouced. I've you
> solved
> the problem with publishing the site news? At the moment we've not many news
> but I suppose we'll got many soon. Is it possible to have the an excerpt of
> the latest
> news on the home page of the web site?
> 
> I've tried also the two different resolutions and are ok.
> 
> The script you're talking in your email related to news publish or to
> resolution adjustment?

It's for the news. It works that way: a perl script is being run 
according to cron schedule. It's connecting to project news database and 
checks if there's something new. Then it creates a html file with the 
news. I wanted you to post some news to see it in action, what this 
created file looks like and so on. And then I'll integrate it with the 
website.

> Derek can you write some text to put in the web site to illustrate our
> integration
> capabilities? Can you coordinate that with Piotr? Integration is a good
> point for
> a system like that. Piotr I think that we need to find a little space for
> that on the site.
> I was thinking the same more or less we have done for Vision, Benefit, and
> What is.

Yes, of course, when I get the text I'll put it online. But I hope it 
won't be too big. I think it would be good to make a brief overview of 
the integration capabilities (just main features) for the front page and 
bigger, more detailed document for download.

Regards
Piotr

> Guys,
>
> Derek sends me an interensting email to discuss some points. I like that
> everybody
> Ashwini, Dobb and Razi gives their opinions about that.
>

Sorry, a mistake in my english. :-((
I would like that Ashwini, Dobb and Razi gives their opinions about this
topic

> >
> > USER AUTHENTICATION MECHANISM: SESSION COOKIE?
> >
> > Presumably a user should log on.  But then what.  What if the user
> > sits there for hours and does nothing?  How will the MSO VBA add-in

Guys,

Derek sends me an interensting email to discuss some points. I like that
everybody
Ashwini, Dobb and Razi gives their opinions about that.

>
> USER AUTHENTICATION MECHANISM: SESSION COOKIE?
>
> Presumably a user should log on.  But then what.  What if the user
> sits there for hours and does nothing?  How will the MSO VBA add-in
> communicate the user's identity with the eDocs server (the "web
> services" provider that the add-in will communicate with using SOAP)?
>
> Well, I could pass id AND password over-and-over (I've left open
> how we want to encrypt the password, for now).
>
> I figured, one of the connection points on the eDocs server web service
> could be logIn( string userName, string passWordSHA1) [or again,
> however password will be encrypted -- maybe we install a digital
> certificate on the user's workstation and they pass that back and
> forth.. however we decide to design it later].
>
> With a login( uid, pwd), then rather than login before each operation,
> perhaps the eDocs server could give the MSO VBA add-in a "session
> cookie."
>
> The eDocs server would remember the cookie correlates to my user.
>
> Then, subsequent operations from this user would carry with them the
> session cookie identifying the user.  As long as this cookie is up-to-date
> (not old, based on some presumably Administrator-set cookie expiration
> property on the server) and known, there would be no need to make another
> login( uid, pwd) call.
>
> So, anyway, the two Use Cases I did were based on this sort of arrangement
> for how eDocs Server and the MSO VBA add-in would agree to authenticating
> the user.
>

For me all the following are a nice to have:

1) User identifies himself using username and password or (better) digital
certificate
(this could be a feature of a further release. The http connection with the
eDocs server web service provider needs to be normal or SSL encrypted.

2) A nice to have additional feature could be have digitally Signed SOAP
messages that goes back and forth
with the server. This could be useful if the user want a further level of
security (Impressions??).

3) After the authentication has been successfully executed necessarly a user
needs to have
a "session cookie" that will be shared between all the applications that
possibly
needs to access eDocs server. We necessarly need to give the possibility to
set a timeout after
 which the cookie wont be valid and the user needs to reauthenticate himself
the first time
he will try to access again the server.

4) What if a user calls for an authentication to the eDocs server and then
sits for hours
doing nothing? I would like to give an "availability timeframe window" where
he can authenticate himself. If the user tries to authenticate outside that
timeframe
the system must give an error message and the process must be reinitiated (I
think
Derek this was your first question)

>
> NAVIGATING THE REPOSITORY FOLDERS REMOTELY
>
> The user could do open( cookie, folderPath, documentName), for example.
>
> The other thing was how to populate the "File Open" dialog that lists the
> Folders and Documents available on the Repository(ies).  So again, I
figure
> there'd be a connection point on the eDocs server to facilitate getting
the
> directory of each Folder.  So it would be like,
>
> getDirectory( cookie, topFolderPath, filterDocumentsByType), for example.
>
> That would be a bit-chatty. :-(  By the same standard, since there could
be
> thousands of documents under management, I wouldn't want the WHOLE
> catalog of documents stored.
>
> A compromise would be to ask for all documents/folders in this folder, and
> then all documents/folders one-level down.

Agreed

>
> Then, if the user goes TWO levels down the folder hierarchy, well, then
make
> another call ...
>
> Anyway, so there's this back-and-forth when the user is navigating through
> the File Open or Check Out dialog boxes, browsing.

I think you're right but I don't think we can't  find anything different.

>
> ONE OFFICE APPLICATION ISN'T ANOTHER FOR LOGGING IN
>
> If the user logs in from Microsoft Word, and then goes to Microsoft Excel,
> the user will not be logged in from there.  In fact, if he does, he'll
have to
> get a separate session cookie from the eDocs server.

We need to find a way to share the session cookie

> This doesn't sound too unexpected (we need one VBA add-in per Office
> application, and they don't generally talk to one another ...)
>
> One possible design would use a local COM server, a process existing
> outside of all Office applications that is started before starting the
first
> Office application.  It could serve as an intermediary for the state (the
> login session cookie) and the Add-ins could consult it to determine
> whether to let the user log in, or conduct other eDocs operations.  It
> may be possible for an Add-in to start it, although I can't guarantee
> even with reference counting that it might not be orphaned (if an
> Office application instance crashes, there would be no way for it's
> Add-in to Release the reference in the local COM server).

We can implement a sort of in-memory link between the add-ins and a
local server. When the apps starts up it inform the server about its
presence.
The local server insert a reference in a list of applications that are
running. That link will be removed when an application closes because
the add.ins will inform the local server about that. During normal
operations the local server will check for application presence looking at
the list of running application. If an application crashes the local server
will
not have any answer back and so it will remove the app from the list.

Any thought about that from everybody??

Regards

Sergio

> First, hello everyone.  I've joined the group to help develop the
Microsoft
> Office integration components, or at least get them kick-started.  :-)
>
> "Ashwini Kumar" wrote on 2002-10-02,
> > I think we need to decide how complicated we would like the search
> > for eDocs to get. Maybe for the time being we should simply stick to
> > the RDF framework and make sure that the document creator
> > associates a metadata with the document.
>
> I agree with your proposal of RDF for the time being, Ashwini.
>
>
> WHY RDF?
>
> RDF is a mature standard and better-understood than ontologies.  It's
> easier (from a software development standpoint) to employ a simpler
> metadata approach.

I agreed on following this approach for our document search strategy.

> I'd like to see a first working release of eDocs as soon as possible,
> versus a full-featured release that bogs down in complexity and which
> might not "get out the proverbial door."   That's why I'd support a
minimal
> feature set for Version 1, so that Version 2, and 3, etc., can evolve into
> the eDocs Document Management System Sergio has envisioned with
> help from a supportive user community.

We hope to have it soon. But now I would like to concentrate on analysis
and design and I absolutely want to finish that phase by the end of this
month.
After that we can think about implementing a prototype.

> A metadata search approach is easier to implement, less demanding
> of network bandwidth in the size of serialized SOAP requests, and
> would be much more reliable across the breadth of "document" types
> business users will use eDocs with from the Microsoft Office suite
> of products.

Right

>
> Speaking from my investigation of a Microsoft Word Add-in, to store
> and retrieve a Word document, it would be easiest to provide meta-
> data (the fields a user optionally fills in as the Document's Properties
> in Word: title, keywords, author, manager, version, etc.) and then
> a BASE64 octet-stream that could be stored on the server as an
> opaque package ("black box").  This wouldn't facilitate full-text
> search though, and serializing the Word Document's Object Model
> would be extraordinarily heavyweight (also brittle to different releases
> of Word, and labor-intensive to code and maintain pre dot NET.)
>
> I can foresee sending metadata, the bare text of the Word
> document as a (very long) xsd:string element so eDocs can
> search the bare, unadorned text, and an octet-stream (which
> would still be stored as a black box).  This may not be as
> applicable to other Microsoft Office applications, like Visio
> diagrams [eg, I want to search for all UML Class Diagrams
> in eDocs concerning class name "*LexicalHandler".]

Right, we need to think about the ability to store every type of
document.

> Actually, Visio 2000 doesn't expose that in it's Object Model
> (spent a weekend trying to get at it to write a code-gen Addin)
> though it may be possible to get at it after the internal COM
> object it uses to handle UML in Visio serializes itself into
> the .VSD file format.  In that case, I wouldn't want the
> octet-stream to be opaque to the repository.  :-)   Or, I
> might use the VBA FileSystemObject in the Add-in to
> save the diagram to disk in a TMP folder, scan it for text,
> and forward that text separately to be searchable (then
> the octet-stream could be opaque, I suppose we want
> to shoot for consistency there... )
>
> In any event, I definately see issues with searching
> Visio diagrams for text.  Support would be incomplete,
> at best. (My recommended practice, if a user has a UML
> Class Diagram in Visio 2000, he or she must list all
> applicable Class Names as keywords for metadata to
> search for them reliably.  Visio XP, I think, can export
> UML to XMI, it might need a Microsoft patch to do it,
> but that could work better.)
>
>
> PROBLEM WITH ADDING FULL-TEXT SEARCH LATER
>
> On the other hand (isn't it awful, having two hands? ;-) ).
>
> The one problem with adding the sophisticated, full-text search
> capability later is Migration for upgrading users.  We would need
> either:
>
>     1. A Migration Plan for going from a keyword-oriented search
>     facility to a full text-oriented search facility in the future.  This
>     would probably involve something tantamount to checking-out
>     and checking-in all revisions (or having smart differencing) of
>     all (the latest) documents.  :-(
>
>     2. Not support migration formally.  Perhaps allow existing
>     documents in a company's repository catalogued with keyword
>     search to remain available for keyword searchs, but be excluded
>     from newer comprehensive text searchs.  But for a pre-existing
>     document revision to be subject to comprehensive text search
>     in an upgrading organization, the user would have to check-out
>     and check-in under the new version.
>
> So, there could be a problem going from a simpler metadata to
> a more comprehensive metadata in the future for early-adopters.
> Administrators will be unhappy if it's not easy to migrate.
>
>
> CONCLUSION
>
> I'd still choose the first hand: RDF and searching on metadata
> about repository documents to begin with.  It increases the
> likelihood eDocs 1.0 happens (if eDocs 1.0 doesn't happen,
> there'll be no first release to migrate from and so nobody has
> that problem).

I think that now we need to be able to use metadata to enable serching
document, to let people be able to use the system with any
particular type of document and for us to mantain things easier.
May be in a next release we can think about full text search with
particular set of documents that needs this functionality.

Ashwini is involved in the task of define a strategy to implement the
RDF framework in our product. We hope to see soon his proposal.

Sergio

> Hi all,
>
> First of all welcome to Derek.
> Now back to the subject. Sergio could you please add some news to our
> project? For example about the website being ready. I can check then if
> the shell script is working properly.
> BTW, I have modified the site and it recognizes the client's resolution
> now.  I made 2 versions: 800x600 and 1024x768 as they are stil most
> popular on the web.
>
> Regards
> Piotr

Great as usual Piotr,

I've tried the site functionalities and works great. I'll add news to the
project
immediately. I was waiting for your ok to let the site be annouced. I've you
solved
the problem with publishing the site news? At the moment we've not many news
but I suppose we'll got many soon. Is it possible to have the an excerpt of
the latest
news on the home page of the web site?

I've tried also the two different resolutions and are ok.

The script you're talking in your email related to news publish or to
resolution adjustment?

Derek can you write some text to put in the web site to illustrate our
integration
capabilities? Can you coordinate that with Piotr? Integration is a good
point for
a system like that. Piotr I think that we need to find a little space for
that on the site.
I was thinking the same more or less we have done for Vision, Benefit, and
What is.

Let me know guys.

Regards

Sergio

Hi all,

First of all welcome to Derek.
Now back to the subject. Sergio could you please add some news to our 
project? For example about the website being ready. I can check then if 
the shell script is working properly.
BTW, I have modified the site and it recognizes the client's resolution 
now.  I made 2 versions: 800x600 and 1024x768 as they are stil most 
popular on the web.

Regards
Piotr

Guys,

on the cvs you'll find the latest release of requirements doc with Derek's
U9 and U15 detailed view description.

Sergio

Derek and Anton,

I would like you coordinate together on the A&D of the integration part of
the eDocs system. Derek is already working
on that and he is, inside the eDocs project, the responsible for that part
of the system.

I'm merging the latest UCs that Derek send me this morning so I can let them
available on the official requirement document
by this evening.

Everybody must remmber that every document regarding the project must follow
the standards layout and formatting rules
used in the requirement and vision docs.

Sergio

First, hello everyone.  I've joined the group to help develop the Microsoft
Office integration components, or at least get them kick-started.  :-)

"Ashwini Kumar" wrote on 2002-10-02,
> I think we need to decide how complicated we would like the search
> for eDocs to get. Maybe for the time being we should simply stick to
> the RDF framework and make sure that the document creator
> associates a metadata with the document.

I agree with your proposal of RDF for the time being, Ashwini.

WHY RDF?

RDF is a mature standard and better-understood than ontologies.  It's
easier (from a software development standpoint) to employ a simpler
metadata approach.

I'd like to see a first working release of eDocs as soon as possible,
versus a full-featured release that bogs down in complexity and which
might not "get out the proverbial door."   That's why I'd support a minimal
feature set for Version 1, so that Version 2, and 3, etc., can evolve into
the eDocs Document Management System Sergio has envisioned with
help from a supportive user community.

THE MICROSOFT OFFICE INTEGRATION VIEW:
A METADATA SEARCH IS BETTER

A metadata search approach is easier to implement, less demanding
of network bandwidth in the size of serialized SOAP requests, and
would be much more reliable across the breadth of "document" types
business users will use eDocs with from the Microsoft Office suite
of products.

Speaking from my investigation of a Microsoft Word Add-in, to store
and retrieve a Word document, it would be easiest to provide meta-
data (the fields a user optionally fills in as the Document's Properties
in Word: title, keywords, author, manager, version, etc.) and then
a BASE64 octet-stream that could be stored on the server as an
opaque package ("black box").  This wouldn't facilitate full-text
search though, and serializing the Word Document's Object Model
would be extraordinarily heavyweight (also brittle to different releases
of Word, and labor-intensive to code and maintain pre dot NET.)

I can foresee sending metadata, the bare text of the Word
document as a (very long) xsd:string element so eDocs can
search the bare, unadorned text, and an octet-stream (which
would still be stored as a black box).  This may not be as
applicable to other Microsoft Office applications, like Visio
diagrams [eg, I want to search for all UML Class Diagrams
in eDocs concerning class name "*LexicalHandler".]

Actually, Visio 2000 doesn't expose that in it's Object Model
(spent a weekend trying to get at it to write a code-gen Addin)
though it may be possible to get at it after the internal COM
object it uses to handle UML in Visio serializes itself into
the .VSD file format.  In that case, I wouldn't want the
octet-stream to be opaque to the repository.  :-)   Or, I
might use the VBA FileSystemObject in the Add-in to
save the diagram to disk in a TMP folder, scan it for text,
and forward that text separately to be searchable (then
the octet-stream could be opaque, I suppose we want
to shoot for consistency there... )

In any event, I definately see issues with searching
Visio diagrams for text.  Support would be incomplete,
at best. (My recommended practice, if a user has a UML
Class Diagram in Visio 2000, he or she must list all
applicable Class Names as keywords for metadata to
search for them reliably.  Visio XP, I think, can export
UML to XMI, it might need a Microsoft patch to do it,
but that could work better.)

PROBLEM WITH ADDING FULL-TEXT SEARCH LATER

On the other hand (isn't it awful, having two hands? ;-) ).

The one problem with adding the sophisticated, full-text search
capability later is Migration for upgrading users.  We would need
either:

    1. A Migration Plan for going from a keyword-oriented search
    facility to a full text-oriented search facility in the future.  This
    would probably involve something tantamount to checking-out
    and checking-in all revisions (or having smart differencing) of
    all (the latest) documents.  :-(

    2. Not support migration formally.  Perhaps allow existing
    documents in a company's repository catalogued with keyword
    search to remain available for keyword searchs, but be excluded
    from newer comprehensive text searchs.  But for a pre-existing
    document revision to be subject to comprehensive text search
    in an upgrading organization, the user would have to check-out
    and check-in under the new version.

So, there could be a problem going from a simpler metadata to
a more comprehensive metadata in the future for early-adopters.
Administrators will be unhappy if it's not easy to migrate.

CONCLUSION

I'd still choose the first hand: RDF and searching on metadata
about repository documents to begin with.  It increases the
likelihood eDocs 1.0 happens (if eDocs 1.0 doesn't happen,
there'll be no first release to migrate from and so nobody has
that problem).

Derek Harmon
sto...@us...

Hello,

Sorry for the delay. I am still flooded with the various possibilites in this field. I must say I found a lot of information on the web regarding document search. Here are some of the pointers.

http://www.dlib.org/dlib/january97/retrieval/01shneiderman.html#relevance

http://www.w3.org/RDF/    (this is about Resource description framework which talks of associating metadata with every document to aid in document search)

http://www.cs.umd.edu/users/hendler/AgentWeb.html  (this paper talks of semantic web Ontologies)

I think we need to decide how complicated we would like the search for eDocs to get. Maybe for the time being we should simply stick to the RDF framework and make sure that the document creator associates a metadata with the document.

Regards,
Ashwini

---------------------------------
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
Ashwini,

I would like to know if you're working on your proposal fo a document's
search strategy. If so can you share with us how this activitiy is going on?
My idea is to finish the requirements analisys for october 15th to begin
examination of implementation details, domain model and so on.

Regards

Sergio

Sergio Ramazzina wrote:

> Piotr I've tried to copy the file to the docs directory but it gives me
> Permission denied error.
> In any case I've seen you've uploaded the zipped one, but I prefer we put it
> the pdf one.
> The doc is attached to this email. Can you upload it?

All right, I already did that.

> I'l investigate about the news and I'll let you know asap.

Great, thanks.

> P.S. Finally now you have the edocs-development mailing list in replay to
> this email

Thanks :-)

Piotr

> Hi all,
>
> Should we add a button to allow the user to see the
> history of changes that had been made to a document or
> folder?  Maybe a simple table view with the revision
> number, date of changes, who changed the document
> last, brief summary given ther reason for the change.

Yes I think this is a good idea but this is implementation. We'll afford
that phase later.

>
> I see that in that in the User Case Anaylsis document,
> document history has been mentioned in U6 and U7 but
> no use case given on how the user can see these
> changes.  Is U8 meant to allow the user to look at the
> history?

Right I'll add it asap.

Regards

Sergio

Hi all,

Should we add a button to allow the user to see the
history of changes that had been made to a document or
folder?  Maybe a simple table view with the revision
number, date of changes, who changed the document
last, brief summary given ther reason for the change.

I see that in that in the User Case Anaylsis document,
document history has been mentioned in U6 and U7 but
no use case given on how the user can see these
changes.  Is U8 meant to allow the user to look at the
history?

DL

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Sergio Ramazzina wrote:
> Piotr,
> 
> I'll forward you this email in case you're not following the struts mailing
> list. I think you need to know what is written inside. If you have already
> read that message scratch it.

Thanks Sergio. I have read about JSF some time ago on the Sun website. 
It looks interesting, but it's still not ready yet. Now, the question is 
are we going to try using it? This article says :

"For applications now (or about to be) under development that have
relatively short term schedules (i.e. the next few months), you
should probably stick with the existing HTML library."

Could we consider our project a short term?

You asked me to have a look at new features of Struts 1.1, especially 
Tiles. The seem to be a good way to provide a clear structure of the 
sites or web based parts of the applications.
Here is an article presenting the possibiites offered by Tiles:

http://www.javaworld.com/javaworld/jw-01-2002/jw-0104-tilestrut.html

Take a look at solutions 6 and 7. I think that they would be most 
interesting for us.

Regards
Piotr

Piotr,

I'll forward you this email in case you're not following the struts mailing
list. I think you need to know what is written inside. If you have already
read that message scratch it.

Regards

Sergio
----- Original Message -----
From: "Craig R. McClanahan" <cra...@ap...>
To: <str...@ja...>; <str...@ja...>
Sent: Wednesday, September 18, 2002 8:09 PM
Subject: [Forward-Looking] Struts and JavaServer Faces

> Many folks on both the STRUTS-DEV and STRUTS-USER mailing lists, have
> wondered at what the future holds for Struts, now that the initial early
> access release of JavaServer Faces has become available.  Here is a
> snapshot of my current thinking on the subject.
>
>
> BACKGROUND:
> ==========
>
> JavaServer Faces (JSF) is being developed as JSR 127 under the Java
> Community Process, with the goal of creating a standard framework for user
> interface components to be used in web applications.  Included will be the
> following basic features:
>
> * User interface component model
>
> * Event handling model
>
> * Validation framework
>
> * Flexible rendering model (plugin support for rendering different
>   kinds of HTML, or different markup languages and technologies)
>
> * A standard RenderKit (and associated Renderers) for generating basic
>   HTML/4.01 markup.  This library is primarily for making JSF useful
>   out of the box, and allow apps to be portable across JSF
>   implementations.  However, we expect a lot of innovation in this
>   area among competing JSF implementations.
>
> All of the above functionality is available via standard Java APIs, and is
> thus not tied to JavaServer Pages (JSP).  However, because a large
> majority of JSF users will also be using JSP, an additional set of
> requirements is included in the JSF specification, including:
>
> * A standard tag library for generic things that are independent of
>   the specific RenderKit in use (such as adding a validator to a
>   component).
>
> * A standard tag library for the basic HTML RenderKit, with a tag for
>   each combination of a component type and a method of rendering that
>   component type.  An example will make this clearer -- consider the
>   UISelectOne component, which represents a list of options, and allows
>   only a single option from the list to be selected.  Such a component
>   can be rendered in three different ways (in the basic HTML RenderKit),
>   each with a different Renderer and a corresponding custom tag:
>
>   <h:selectone_listbox>         Display a list of all the possible
>                                 options (expanding the box to include
>                                 all of them so that no scrollbar is
>                                 required).
>
>   <h:selectone_menu>            Display as a combo box (the traditional
>                                 HTML <select> element with size="1").
>
>   <h:selectone_radio>           Display as a set of radio buttons and
>                                 corresponding labels.
>
> Note that the application developer doesn't know or care which mechanism
> was used to display this component -- that's up to the page author, who
> will pick the desired representation by virtue of which tag he or she
> selects (at the Java API level, you make this choice by setting the
> "rendererType" property on the component instance).  This is one of the
> many advances that JSF provides over Struts tags, where there is one and
> only one way to render each individual element.
>
> There are also provisions for creating more complex components like grids,
> tree controls, and the like -- a common theme you will see is "compose
> complex things out of little things" -- that is accomplished in JSP by
> nesting component tags inside each other, just like you nest HTML <input>
> elements inside a <form> element.
>
> For more information about JavaServer Faces, and an early access draft of
> the specification (and an early access version of the RI that corresponds
> to an even earlier draft of the spec), you'll want to bookmark:
>
>   http://java.sun.com/j2ee/javaserverfaces/
>
> In addition, there is a forum on the Java Developer Connection (free
> registration required) focused on JavaServer Faces, so please ask your
> general Faces-related questions there instead of here.  Here's a direct
> link to the forum page:
>
>   http://forums.java.sun.com/forum.jsp?forum=427
>
> Note that JavaServer Faces depends on Servlet 2.3 and JSP 1.2 (i.e. J2EE
> 1.3 containers).
>
>
> HOW DOES THIS AFFECT STRUTS?
> ===========================
>
> At first glance, the low level components sound a lot like the struts-html
> tag library that Struts users know and love.  Indeed, there is a very
> substantial amount of overlap.  So, what's going to happen?
>
> In my JavaOne BOF on Struts (March, 2002), I made the statement that
> Struts would have a very clean integration with JSF, so that you can use
> JSF components in your user interface, but continue to use the controller,
> Actions, and associated business logic.  Indeed, I stated that it will be
> possible to transition your application from using Struts HTML tags to
> using Faces component tags, one page at a time -- in most cases, with zero
> changes to the business logic or Action classes and minimal changes to the
> <forward> elements in your struts-config.xml configuration file.
>
> Along with developing JavaServer Faces itself (I am the specification lead
> for JSR-127), I have been working on just such an integration library for
> Struts (1.1 only; sorry in advance to 1.0 users).  While not completed
> yet, it is clear that the goals stated in the previous paragraph are
> achieveable with the current evolving design of JSF.  While things can
> always change in the future, many JSR-127 expert group members consider
> high quality integration with Struts to be an important success factor for
> JavaServer Faces to be accepted.  Therefore, I do not expect that JSF will
> evolve in ways that make this kind of integration difficult or impossible.
>
> From the developer's perspective, you will need to do only the following
> to start using JSF components in your pages:
>
> * Add a new struts-faces.jar file, and the JAR files for an
>   appropriate JSF implementation, to your /WEB-INF/lib directory.
>
> * Note that JSF and the JSP Standard Tag Library (JSTL) interoperate
>   very nicely, so you will also be able to use JSTL tags in your
>   new pages if you wish to.
>
> * Add a couple of elements to your web.xml deployment descriptor,
>   corresponding to the requirements outlined in Chapter 9 of the
>   JSF specification.
>
> * Transition one page at a time to use the new tag libraries,
>   making an appropriate modification to the <forward> elements
>   for your pages (the URL needs to change to meet Faces requirements).
>
> The integration library will be available as a separately packaged
> download that runs with Struts 1.1, and will include a converted copy of
> the canonical struts-example web application so that you can see exactly
> what had to change in order to use Struts with JSF.
>
> Besides the integration classes themselves (primarily an implementation of
> the JSF ApplicationHandler API), the library will include some
> Struts-flavored components and renderers that provide functionality
> similar to that provided by the existing struts-html tags, when this is
> not provided by the standard JSF components.  For example, there will be a
> Struts version of the UIForm component that accepts an "action" attribute
> that looks up the corresponding action mapping, and creates the form bean
> as needed, just like the <html:form> tag does today.
>
> The good news -- development of this integration library is well under
> way.
>
> The bad news -- you can't see it quite yet.  This is primarily because it
> relies on changes to JSF that have occurred since the early access release
> of the RI was published, so you wouldn't be able to use it anyway.
> However, as soon as it is feasible, this library will be added to the
> "contrib" folder of Struts, with the sources (and downloadable
> distributions) available under the usual Apache license terms.  (The
> source code will also give you a head start at creating your own JSF
> components, too).
>
>
> SO WHAT USER INTERFACE TECHNOLOGY SHOULD I CHOOSE?
> =================================================
>
> Everyone's functionality and schedule requirements are different.
> However, the following points summarize my basic recommendations and
> thoughts about the future:
>
> * If you have existing Struts-based applications that use the existing
>   HTML tag library, feel free to continue to use them if you wish.
>   Struts 1.1 offers full support for this existing functionality.
>
> * Once the integration library becomes available, you should do some
>   experimenting and prototyping to determine the effort required to
>   migrate your apps to the new JSF component architecture (I'm betting
>   that the extra functionality you gain by doing this will be well
>   worth the effort in many cases).  As described above, the actual
>   migration can be done piecemeal -- it doesn't need to happen all
>   at once.
>
> * For applications now (or about to be) under development that have
>   relatively short term schedules (i.e. the next few months), you
>   should probably stick with the existing HTML library.
>
> * For applications with a longer lead time, seriously consider waiting
>   for the ability to use JSF components instead of the Struts HTML
>   tag library.  Doing this will let you leverage not only the standard
>   HTML components that come with JSF out of the box, but also the rich
>   libraries of JSF components likely to be created by third parties in
>   the future (including Struts developers).
>
> For Struts after 1.1 is released, the developers haven't yet had formal
> conversations (which will happen on STRUTS-DEV) about what a future Struts
> will look like.  However, I'm going to continue to advocate a long term
> migration to using standards like JSF and JSTL when they are available,
> and de-emphasize the further development of the Struts proprietary tag
> libraries.
>
> The Struts tag libraries have had a tremendous positive impact on the
> development of the standard Java APIs for user interfaces.  I joked with
> the JSTL spec lead that Struts users would *never* accept JSTL without an
> expression language at least as powerful as the Struts one; and there is
> more than a little truth to that statement :-).  The same thing is
> happening now for the HTML tags -- and it's time for us to start migrating
> to the standards, which gives us the time to focus on extending Struts in
> other directions in the future.
>
> Comments?  Questions?  If it's about Struts, or Struts/JSF integration,
> feel free to ask about these issues on STRUTS-DEV or STRUTS-USER (although
> I'm going to be relatively incommunicado over the next week; I'll be in
> Yokohama at JavaOne Japan and only intermittently connected to email).
> Questions about JSF itself should be addressed to the JSF forum at the URL
> listed above.
>
> And thanks to all of you for your continued support and use of Struts --
> the community that has developed around this framework continues to amaze
> and humble me.
>
> Craig McClanahan
>
>
> --
> To unsubscribe, e-mail:
<mailto:str...@ja...>
> For additional commands, e-mail:
<mailto:str...@ja...>
>

> I have checked it with IE 5.5, Opera 6.04 and Mozilla 1.0. There werer
> some problems with layers' positioning. It looks like Opera and Mozilla
> are using bit different method to calculate the layer's position. I made
> a workaround to that problem but I'll try to find more "elegant"
> solution to that. I didn't check it under Netscape 4.x or 6 because I
> don't have these browsers installed. I dumped Netscape 4.x for Mozilla.
> And NN6 was so slow I removed it after few days. Mozilla is based on the
> same engine as NN6 so it should look the same. But we can do some
> testing with Netscape if necessary.

No don't bother about that. It's enough. I'll wait to see the site online.

>
> > I've read your navigation proposal document and I sent it back to you
with
> > my correnctions. I don't know if you have seen it. I'll wait your
opinion
> > about that to let us complete that analisys
> > asap.
>
> Yes, I read it this morning. I can see your points. And it looks good to
> me. I'm thinking about the technical side of that now, the layout is
> going to be complex but I don't mind.
>
> By the way, could you set Reply-to field to point to edocs mailing list?
> It would make communication bit easier - now it's necessary to change
> the recipient address when replying to the posts and it's easy to forget
> about that.

I can set my reply address to edocs mailing list but, because this is my
personal email, if I do that thing everyone, also common people and my
friends, will reply to the list. And it's not a good idea.

Regards

Sergio

> Sergio Ramazzina wrote:
> > Piotr do you think it would be possible to put a pdf of the latest
version
> > of the Vision document on the project web site to let everyone be able
to
> > download it? Also can we add to the site a section where we can put the
> > latest architecture chapter?
>
> Yes, no problem with that. But do we have to create a special section
> for that? It fits well into documentation section in my opinion.

Agreed. Proceed.

>
> The website should be ready by Sunday. I'm still playing with the idea
> of making 2 versions of it. I could use JavaScript to detect the
> client's resolution to make it fit to 800x600 or 1026x768. What do you
> think?

I think may be a good idea Piotr. It could be more flexible. Are we
compatible with IE, Netscape and Opera (at least)?

I've read your navigation proposal document and I sent it back to you with
my correnctions. I don't know if you have seen it. I'll wait your opinion
about that to let us complete that analisys
asap.

Have a good week end to you and other team members.

Bye

Sergio

Piotr,

Im sending you your document with my corrections and proposals. Let me know
what are your opinions.

Regards. Thanks

Sergio

----- Original Message -----
From: "Piotr Kreglicki" <pkr...@wp...>
To: "edocs-development mailing" <edo...@li...>
Sent: Thursday, September 26, 2002 10:41 PM
Subject: [Edocs-development] Navigation path

> There is a little commentary inside.
>
> Regards
> Piotr
>

Guys,

under CVS I've created a documentation folder. That is the our project
documentation's folder and there you'll find the latest vision docs and
requirement analysis doc. Let me know if you have any problem with CVS.

Regards

Sergio

Excuse me Ashwini. I've added a guy called Ashwini to the project but he =
was'n the right one. I'm really sorry.=20
Can you please give me your sourceforge nick so I can add you (the right =
one)?

I had the idea of repositories with distribuited folders to give =
customers more flexibility. If we assume that this feature can introduce =
security issues or that can let the system became not too manageable, =
then we can change our strategy centralizing repository's folders. About =
that I ask also for the opinion of  the other team members.=20

But please can you clarify me what did you intend when you said "If the =
documents themselves are stored in a distributed fashion as mentioned, =
then they are potentially insecure till such time they are backed up".

Regarding attachments that cames from eDocs mailing system I've no =
problem. I don't know about other people.

Bye

Sergio
  ----- Original Message -----=20
  From: Ashwini Kumar=20
  To: Sergio Ramazzina ; Razi ; Piotr Kreglicki ; Laurence Chiu ; Dobb =
Lou ; Anton ter Velde=20
  Sent: Friday, September 27, 2002 1:11 AM
  Subject: Re: Vision document update

  Hello,=20

  Thanks Sergio for the vision document. With due respect, I must =
express my concern about what is proposed. If the documents themselves =
are stored in a distributed fashion as mentioned, then they are =
potentially insecure till such time they are backed up. Back up and =
restore themselves may be complicated in a distributed environment. =
Perhaps organizations will have a comfort factor if the documents are =
stored in a centralized repository containing other repositories.=20

  This way check in and check out may be achieved.=20

  My name does not figure in the list of developers in the eDocs common =
site. Could Sergio please add my name?. There is however another person =
who shares my first name.=20

  I wonder if my mail system is not set up properly. But I see all =
attachments from the edocs mailing system  as Base64 encoded. I know it =
is easy to decode the Base64 portion but maybe there is an easier =
solution. I look forward to reading the documents from CVS.=20

  Thanks,
  Ashwini=20

  =20

   Sergio Ramazzina wrote:=20

    Architecure section added. Razi this document's section will respond =
(I
    hope) to the questions you made me some days ago.

    We need to have a repository for our documentation files. An idea =
could be
    to create a directory in the CVS repository. Anoyone agree or =
someone has a
    better suggestion?

    Regards

    Sergio
    > ATTACHMENT part 2 application/x-zip-compressed name=3Dedocs - =
vision .zip=20

-------------------------------------------------------------------------=
-----
  Do you Yahoo!?
  New DSL Internet Access from SBC & Yahoo!

edocs-development Mailing List for edocs (Page 2)

edocs-development — Developers mailing list