Orbeon PresentationServer is now Orbeon Forms

Dear list,

We are glad to announce that Orbeon PresentationServer has a new name:
Orbeon Forms. All the details are available in this blog post:

http://www.orbeon.com/blog/2006/11/05/orbeon-presentationserver-is-now-orbeon-forms/

Practically, nothing changes for OPS users: the source code is the
same, the license is the same, and our development strategy is the
same. We hope that the temporary confusion that may arise from the
name change will be largely compensated by the benefits of having a
shorter, more descriptive name!

With our best regards,

-The Orbeon Team

--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Erik,

I have finally a break in other activities (with OPS 3.01) and am  
taking a look at the latest release(s). I've sort of been putting  
this off, as I don't want to find bad news. I had to do a fair amount  
of work to find a way that worked for us to have one instance of OPS  
and serve many different domains with their own content. Much of this  
work was in terms of file layout (directory structure) - some issues  
were addressed with links and some by moving files - everything has  
been working well. I hope it will continue to do so ;-)

I downloaded the 3.5M1 and then the latest nightly build. I haven't  
gotten into comparing them with 3.01 and what we ended up with, but  
one thing is obvious - things changed a lot between 3.5M1 and now.  
Part of putting off this task was to wait until things were stable,  
but I was concerned not to leave it too late in case I did find  
issues. Do you think the file layout will change again before 3.5 Final?

Calling it Orbeon Forms is probably a good move in marketing terms.  
The more people using OPS is obviously better for us all. The XForms  
content, indeed the whole idea, has changed/grown a lot since I first  
happened upon OPS. I was looking for an XML pipelining system that  
included XSLT2 - OPS fitted the requirements very nicely, the  
commitment to standards just what we wanted and XForms was a nice bonus.

For us, the "presentation server" remains the key reason for using  
OPS. I guess that the further work to produce a standard for  
pipelining might make it more of a commodity matter, while enabling  
XForms in the current state of the web is more of a differentiator.  
Still, an effective implementation of the pipelining remains vital.  
While most of the work going forward is undoubtedly with XForms, I  
hope we will never reach the point where the "presentation server"  
becomes the "poor cousin".

Anyway, I guess I need to stop calling it OPS ;-)
(And objectweb will have to stop calling it presentation server)

Thanks again
and best regards
Colin




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Colin,

 > I have finally a break in other activities (with OPS 3.01) and am
 > taking a look at the latest release(s). I've sort of been putting
 > this off, as I don't want to find bad news. I had to do a fair
 > amount of work to find a way that worked for us to have one instance
 > of OPS and serve many different domains with their own content. Much
 > of this work was in terms of file layout (directory structure) -
 > some issues were addressed with links and some by moving files -
 > everything has been working well. I hope it will continue to do so
 > ;-)

Great!

 > I downloaded the 3.5M1 and then the latest nightly build. I haven't
 > gotten into comparing them with 3.01 and what we ended up with, but
 > one thing is obvious - things changed a lot between 3.5M1 and now.

The directory structure of the resources has been fairly heavily
reworked, yes. The result is a much simpler directory structure which
should make it much easier to get started with Orbeon Forms, with just
two directories: "config" and "apps"! All the private resources were
moved to two JAR files, ops-resources-private.jar and
ops-resources-public.jar. Unneeded files have been removed (like the
example-descriptor.xml files). Images have been moved to places where
they make sense. The top-level page flow is reduced to just a few
lines. Etc. This will also make it much easier to upgrade to newer
versions of Orbeon Forms.

 > Do you think the file layout will change again before 3.5 Final?

I hope not in a major way, but the big changes from last week are
still fresh, so it's hard to guarantee that there will be no changes.

 > Calling it Orbeon Forms is probably a good move in marketing
 > terms. The more people using OPS is obviously better for us all. The
 > XForms content, indeed the whole idea, has changed/grown a lot since
 > I first happened upon OPS. I was looking for an XML pipelining
 > system that included XSLT2 - OPS fitted the requirements very
 > nicely, the commitment to standards just what we wanted and XForms
 > was a nice bonus.

 > For us, the "presentation server" remains the key reason for using
 > OPS.  I guess that the further work to produce a standard for
 > pipelining might make it more of a commodity matter, while enabling
 > XForms in the current state of the web is more of a
 > differentiator. Still, an effective implementation of the pipelining
 > remains vital. While most of the work going forward is undoubtedly
 > with XForms, I hope we will never reach the point where the
 > "presentation server" becomes the "poor cousin".

Thanks for the support and understanding. We are convinced the name
change is a good move.

 > Anyway, I guess I need to stop calling it OPS ;-) (And objectweb
 > will have to stop calling it presentation server)

Yes, there are a few places where we still must change the name. We
will probably keep the old name in some places, like "ops-users" as it
is inconvenient to move to a new mailing-list.

-Erik

--
Orbeon Forms - XForms Everywhere
http://www.orbeon.com/blog/




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Erik,

thanks for the quick reply.

On Nov 20, 2006, at 1:10 PM, Erik Bruchez wrote:
I had configured things so that OPS resources such as images and js &  
css files were served by Apache2. Have any of them gone into the jar  
files, and does that mean they will have to be served by Tomcat5?

> > Do you think the file layout will change again before 3.5 Final?
>
> I hope not in a major way, but the big changes from last week are
> still fresh, so it's hard to guarantee that there will be no changes.

I'm heading out of town in the morning for Thanksgiving, so I can let  
it have another week to bake ;-)

Best regards
Colin




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Colin,

 > I had configured things so that OPS resources such as images and js
 > & css files were served by Apache2. Have any of them gone into the
 > jar files, and does that mean they will have to be served by
 > Tomcat5?

Excellent question, and I think we have an excellent response ;-)

One of the goal of the new ops-resources-public.jar is that public
resources (i.e. the ones that can make it to the web browser) can be
upgraded in one shot, and that they do not pollute your resource
space.

However, because they are in a JAR, it is also trivial to unzip the
JAR and have all of its contents served by Apache.

 > I'm heading out of town in the morning for Thanksgiving, so I can
 > let it have another week to bake ;-)

Have a great Thanksgiving!

-Erik

--
Orbeon Forms - XForms Everywhere
http://www.orbeon.com/blog/




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Erik,

finally back this week into looking to make this conversion. Here I  
want to record my progress and raise some questions - if I miss  
anything, please let me know!

Some of what I will mention is covered in the doc (home-changes-35)  
included with the nightly build but not yet on the orbeon.com  
documentation pages.

Looking at what comes in the ops.war, we have two directories: WEB-
INF as before and xforms-jsp.
I can't see anything relevant in xforms-jsp and am completely  
ignoring it.

I have a directory in /opt/tomcat5/webapps for my app.
So I replaced the WEB-INF in there with the new one.

I re-applied my edit to the web.xml to run my prologue.xpl instead of  
pageflow.xml, which identifies which site we are serving and  
therefore which documentroot to use, and thereby which actual  
pageflow.xml to use.

(as the doc says) It seemed that a lot has now been moved into  
resources/apps, so I moved my directory with all my core xpl and xsl  
into there.

A lot of what I had developed need to be based on relative file paths  
- so far this has meant that I had to redo all my symbolic links from  
the documentroot to the core xsl and xpl files. There are probably a  
few other places where I will have to amend path creation in xsls,  
but so far most things seem to be hanging together simply by relinking.

The first problem is that, unlike before, now the demo/portal page  
wrapper (heading and side menu) insists on coming out with my pages.  
This is from the config/theme-portal.xsl (mentioned in doc, but not  
how to operate without it - I have achieved this through editing  
config/epilogue-servlet.xpl to instead use config/theme-plain.xsl)

Now of course we get to the meat
- everything that has been subsumed into ops-resources-private.jar  
and ops-resources-public.jar.
Up to this point, I get 404's on everything in these jars.
Unpacking them inside lib doesn't seem like a great idea.

I'm concerned that both private and public have an ops directory with  
similar sub-directories, but as the private doesn't appear to have  
any css, js or image files, I should be accepting its private and  
leave it alone - probably/hopefully that part will work even in my  
environment ;-)

There is a naming conflict between public/config/theme and resources/
config/theme - ironically it seems the files in public are duplicated  
in resources, and resources has extra (images) files.

Which leaves me with public/ops - in other words, I need to create  
the symbolic links from document root to ops and config (just as I  
did before, only now they are in slightly different places - I had  
set myself up by deleting my old symlinks for these before I did  
anything else so I could more easily identify what I was missing -  
happily we can resort to old cliches such as 'the more things change,  
the more they stay the same' ;-)

Voila! everything now loads - including orbeon.css - oh yes, now I  
remember I used to empty that - and now it even looks like one of my  
sites again. (Well, my forms still look a little different, will have  
to investigate further there).

When I first looked into the public and private jars the other week,  
I was concerned that to make the links effective I would have to  
reorganize/merge/whatever the directories, and that would have been  
very costly in terms of maintaining the setup in the future. On  
MacOSX there is a great tool called filemerge (presumably other  
platforms have something similar) which can identify which  
directories and files have changed from one version to the next. It  
works fine when everything stays where it is, but not if a lot of  
repackaging is needed each time.

If I have done everything now and everything has been done right  
(?!?!), this "upgrade" has taken me about four hours, including  
worrying the other week, comparing and testing this week, and doing  
this write up. Which isn't as bad as I was worrying ;-)

Now I can/need to get into some real testing, to see if applications  
actually still work, and if the forms are really quicker to load etc,  
and maybe even get back to my caching questions ;-)

I'm assuming this extra time has given you extra confidence that you  
will stick with this new layout for the foreseeable future.
Are you planning another milestone release or are we looking forward  
now to the final release?

Thanks & regards
Colin


On Nov 20, 2006, at 6:12 PM, Colin O'Brien wrote:



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Colin,

 > Looking at what comes in the ops.war, we have two directories: WEB-INF
 > as before and xforms-jsp.
 > I can't see anything relevant in xforms-jsp and am completely
ignoring it.

Right, xforms-jsp just contains some examples of how to produce XForms
with JSP.

 > I have a directory in /opt/tomcat5/webapps for my app.
 > So I replaced the WEB-INF in there with the new one.
 >
 > I re-applied my edit to the web.xml to run my prologue.xpl instead of
 > pageflow.xml, which identifies which site we are serving and therefore
 > which documentroot to use, and thereby which actual pageflow.xml to use.
 >
 > (as the doc says) It seemed that a lot has now been moved into
 > resources/apps, so I moved my directory with all my core xpl and xsl
 > into there.
 >
 > A lot of what I had developed need to be based on relative file paths -
 > so far this has meant that I had to redo all my symbolic links from the
 > documentroot to the core xsl and xpl files. There are probably a few
 > other places where I will have to amend path creation in xsls, but so
 > far most things seem to be hanging together simply by relinking.
 >
 > The first problem is that, unlike before, now the demo/portal page
 > wrapper (heading and side menu) insists on coming out with my pages.
 > This is from the config/theme-portal.xsl (mentioned in doc, but not how
 > to operate without it - I have achieved this through editing
 > config/epilogue-servlet.xpl to instead use config/theme-plain.xsl)

Yup, that's exactly the right way to deal with it at the moment.

 > Now of course we get to the meat
 > - everything that has been subsumed into ops-resources-private.jar and
 > ops-resources-public.jar.
 > Up to this point, I get 404's on everything in these jars.
 > Unpacking them inside lib doesn't seem like a great idea.

You shouldn't need to unpack them. The contained resources are loaded
by the ClassLoaderResourceManagerFactory configured in web.xml.

 > I'm concerned that both private and public have an ops directory with
 > similar sub-directories, but as the private doesn't appear to have any
 > css, js or image files, I should be accepting its private and leave it
 > alone - probably/hopefully that part will work even in my environment ;-)

There is no reason it shouldn't, really.

 > There is a naming conflict between public/config/theme and
 > resources/config/theme - ironically it seems the files in public are
 > duplicated in resources, and resources has extra (images) files.

In fact only 3 CSS files are duplicated. They probably shouldn't be. I
entered a bug:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=306498&group_id=168&atid=350207

 > Which leaves me with public/ops - in other words, I need to create the
 > symbolic links from document root to ops and config (just as I did
 > before, only now they are in slightly different places - I had set
 > myself up by deleting my old symlinks for these before I did anything
 > else so I could more easily identify what I was missing - happily we can
 > resort to old cliches such as 'the more things change, the more they
 > stay the same' ;-)

ops-resources-public.jar contains resources such as CSS, JavaScript,
etc. that are public, i.e. allowed to make it to a client web
browser. It is also meant to be simply unpacked so that its contents
can be served directly by Apache, for example. So feel free to deal
with this one as you please :-)

 > When I first looked into the public and private jars the other week, I
 > was concerned that to make the links effective I would have to
 > reorganize/merge/whatever the directories, and that would have been very
 > costly in terms of maintaining the setup in the future. On MacOSX there
 > is a great tool called filemerge (presumably other platforms have
 > something similar) which can identify which directories and files have
 > changed from one version to the next. It works fine when everything
 > stays where it is, but not if a lot of repackaging is needed each time.

I dont't think you should have to do that.

 > If I have done everything now and everything has been done right (?!?!),
 > this "upgrade" has taken me about four hours, including worrying the
 > other week, comparing and testing this week, and doing this write up.
 > Which isn't as bad as I was worrying ;-)

Very good!

 > Now I can/need to get into some real testing, to see if applications
 > actually still work, and if the forms are really quicker to load etc,
 > and maybe even get back to my caching questions ;-)
 >
 > I'm assuming this extra time has given you extra confidence that you
 > will stick with this new layout for the foreseeable future.
 > Are you planning another milestone release or are we looking forward now
 > to the final release?

Thanks for all the feedback.

We are aiming for the final release at this point, although if
necessary we could do an RC release just before.

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Erik,

On Dec 8, 2006, at 3:39 PM, Erik Bruchez wrote:
As discussed below (in original email), I am unpacking them both so  
they can be served by Apache2 and accessible from multiple virtual  
hosts. As things are, they work for me - that is, with these css files in  
resources/config/theme.
I hope you are not thinking of having them only in public/config/
theme - that wouldn't work as well, for me.

This reminds me of another concern (so far ungrounded ;-) that I had  
coming into the conversion - that there might not be a sufficiently  
clear concept of separation of directory naming and contents, of OPS  
directories and application directories - by which I mean, I need to  
be able to achieve a one to one mapping between what the URL says  
(which amongst other things, as your book recommends, hides details  
of how the site is generated, so no ops in our urls - which is after  
all one of the reasons I gave up on webobjects) between what the URL  
says and where the files are - so for example, if the URL says /
images/file.jpg then /images can only map to one place - in this  
example, to /virtualhost/images - so it couldn't simultaneously map  
to /ops/images. Happily this is still not a problem. But I just  
wanted to emphasize this as a potential issue to be alert to when  
looking to lay out OPs files.

Thanks again
best regards
Colin







--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

On 12/13/06, Colin O'Brien <[hidden email]> wrote:
> As discussed below (in original email), I am unpacking them both so
> they can be served by Apache2 and accessible from multiple virtual
> hosts.

Colin,

The files in ops-resources-private.jar are XPL, XSLT, schema, ... They
are only loaded internally by Orbeon Forms. So if you want some files
to be served by the Apache HTTP server, you only need to uncompress
ops-resources-public.jar.

Alex
--
Blog (XML, Web apps, Open Source):
http://www.orbeon.com/blog/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws