>-----Original Message-----
>From: Jose Badeau [mailto:[email protected]]
>Sent: Monday, January 23, 2012 2:54 AM
>To: [email protected]
>Subject: Questions
>
>Hello Rave Team,
Hello Jose. Welcome!
>
>First off, congratulations on your current progress and am looking forward
>to seeing Rave graduate out of the incubation phase :).
>
>Now on to my questions and thoughts. I came across Rave when looking for
>production ready shindig implementations that i could as a basis for my
>portal. I came across a few such as WSO2, and JIRA and CQ5. Howevere, none
>really were suitable either because of licensing or inability to be
>extended or embedded. I came across Rave and liked the idea of being a
>pluggable framework with the intention of being extended or used as a basis
>for a framework
>
>For the past 5 years I have been involved in writing various portal/widget
>frameworks for large Swiss banks, one of which was based or websphere
>portal and a few which were completely custom. I made allot of mistakes and
>am hoping I can have a few questions answered about the direction of Rave
>and contribute where I can.
That would be great. We are more than willing to answer questions and actively
solicit contributions from the community.
>
>1. Will there be any type of SPI for navigation (pages) and content(layout,
>widgets) such as like what is available for webshphere portal?
It is our goal to make everything in Rave replaceable by custom components;
especially persistence. I haven't ever used or seen the Websphere SPI, so I
can't comment on whether or not what we are doing is similar. We are trying to
develop a simple, intuitive object model that balances complexity &
flexibility. To this, we have well defined interfaces for persistence & other
"pluggable" components that gives you an SPI to code to.
>
>2. Are there any ideas about providing OSGI bundles of RAVE, shindig,
>renderers, security, model, etc.
We do have someone who (was) is looking at creating OSGI bundles for the
different Rave components. I will let him comment on how far along that effort
is.
>
>3. I am not a big fan of extending by overlay. Although simple, it will
>generally be a maintenance nightmare for clients when trying to upgrade
>versions as developers tend to just copy a jsp and modify it. This is a
>tricky area and admit that it is not easy to find a solution.
We intend overlay to be just one method of extension. Most of us have similar
concerns as you do and want to see extensibility make its way to the front end
as well.
>I am
>currently coming up with xml deceleration (format is not important) which
>allows pages, to be laid out. Here is a snippit:
>
> <Widget id="toolbar" abstract="false" skin="default"
>container="shindig" type="iframe" url="/toolbar">
> <Modes>view,edit,help,
>minimized,maximized</Modes>
> <Publishes-Topics>search.*</Publishes-Topics>
> </Widget>
>
> <Widget id="google" abstract="false" skin="default" container="shindig"
>type="iframe" url="google.com">
> <Modes>view,edit,help,minimized,maximized</Modes>
> <Publishes-Topics></Publishes-Topics>
> <Consumes-Topics>search.*</Consumes-Topics>
> </Widget>
>
> <Widget id="yahoo" abstract="false" skin="default" container="shindig"
>type="iframe" url="yahoo.com">
> <Modes>view,edit,help,minimized,maximized</Modes>
> <Publishes-Topics>Publishes-Topics>
> <Consumes-Topics>search.*</Consumes-Topics>
> </Widget>
>
> <Layout name="HeaderNavFooter3Row">
> <!-- BORDER -->
> <Container id="border" layout="border" config="{gutters:false}">
> <Area id="header" settings="{region:'north', height:'150px'}" />
> <Area id="navigation" settings="{region:'west', margins:'5 0 0
>0', width:'175px'}" />
> <Area id="center" settings="{region:'center', margins:'35 5 5
>0', autoScroll:true}">
> <!-- COLUMNS-->
> <Container id="column" layout="column"
>config="{anchor:'100%'}">
> <Area id="col1" settings="{autoScroll:true'}" />
> <Area id="col2" settings="{autoScroll:true}" />
> <Area id="col3" settings="{autoScroll:true}" />
> </Container>
> </Area>
> <Area id="footer" config="{region:'south', height:'80px',
>margins:'5 0 0 0'}" />
> </Container>
> </Layout>
>
> <root-node id="root1" theme="default" skin="default" layout="default">
> <Group-Node id="group1" title="node-group1.title">
> <Parameter id="foo">bar</Parameter>
> <Parameter id="foo">bar</Parameter>
> <Page-Node id="home" title="node-group1.home.title"
>layout="HeaderNavFooter3Row">
> <Parameter id="foo">bar</Parameter>
> <Parameter id="foo">bar</Parameter>
> <Content>
> <Add widget="toolbar" to="header"
>instance-id="home.toolbar" />
> <Add widget="google"
>to-area="border.center.column.col1" instance-id="home.googleSmall" />
> <Add widget="yahoo" to-area="border.center.column.col2"
>instance-id="home.googleLarge" />
> </Content>
> </Page-Node>
> </Group-Node>
> </root-node>
>
> <Url-Mapping node="root1.group1" label="urlmapping-root1.group1.title">
> <Url-Mapping node="root1.group1.home"
>label="urlmapping-root1.group1.home.title"/>
> </Url-Mapping>
>
>4. Are there any plans for themeing Rave with SASS/Compass like how ExtJs
>has done. it would be great if clients could just use a compass/sass
>template to extend the default theme or create a new one. currently just
>using a custom css is quite cumbersome. I am currently creating one for
>myself and would be happy to donate it.
Another community member was looking at using Lesscss & Bootstrap. I know the
two approaches are hotly debated [1] and we as a community haven't really
picked one. Since each of you is currently working on an implementation for
Rave, we could evaluate each one in context and reach a consensus about which
strategy to go forward with.
>
>5. There are some strange layout issues related to widget layout and drag
>an drop such as the regions/widgets do not take up the full space of the
>pageContent container which leavse a right side gutter. Widgets do not
>dragNDrop easily, there is a huge pixel buffer to help but it looks bad and
>is difficult to get working. There is a strange issue with padding on the
>regions css class. My question is are there any plans to use existing css
>grid systems such as 960 or 1140? Are there any plans to use an existing JS
>grid layouts such as dojo grid?
I have noticed the same issues, and I know others have as well. They
definitely need to be fixed and we have tickets in JIRA for most of them. If
you see ones we haven't captured, please add them to JIRA. As for the
frameworks, if it is light-weight, simple & results in less work for downstream
developers, my personal opinion is that we should take a look.
>
>6. Will there be support for a client-side api to generate navigation,
>layout and widgets instead of using the tiles to generate markup? It would
>also be very nice to render a widgets outside of the pageContent area. What
>about client-side API for switching pages, history, logging, tracing,
>metrics, etc?
Some of these are in the works, but others are not. My suggestion would be to
open up tickets for the ones you would like to see (that don't already have
tickets) and start a discussion around them. Providing patches for the
implementations wouldn't hurt either
>
>7. When developing javascript api, please use prototypical inheritance
>instead of inner function closures. I would recommend something like
>qooxdoos class system which supports thungs such as interfaces, statics,
>singletons, interfaces, abstract, interfaces, mixins and inheritance. Write
>your api so that it can be extended otherwise developers will just copy
>the whole js file or worse, modify the original. Don't try to protect
>javascript developers too much with private methods, just make clear what
>is public and what is not. There are always cases where the public api is
>not enough so better that they can use it with the consequences than
>copying whole rave files which lead to a maintenance/upgrade nightmare.
IMO this might be best served as a separate discussion topic, but an important
one.
>
>8. Any ideas for an export format of the portal such as liferay archive or
>websphere xmlaccess? How do you plan to move from testing environments
>to
>production?
Personally, I haven't thought much about this, but I think other have ideas
towards this.
>
>9. Any plans for url-mapping which map a pretty names (services(en)|
>servicios(es)) to a page. e.g. /app/page/view/18 = /services |
>/app/page/view/18 = /servicios.
We need a ticket for it, but I agree that we should use tuckey or other
rewriter to simplify the URLs
>
>10. Have not looked into this yet but is there support for public pages via
>anonymous or guest users? External pages like the login page will not
>suffice for portals with allot of public pages.
There isn't yet, but as we build out the team page we will probably need to
entertain this. Also, others in the community have different designs on what
they will use Rave for and probably have ideas toward a solution.
>
>11. Will you be documenting all steps taken to combat browser/web security
>issues (very important when being evaluated for use on the on internet by
>large companies)
I don't think anyone has explicitly stated this desire in the community, but it
is a good idea.
>
>12. when can we expect java and javascript documentation?
There is a good amount now for the Java side (Javadocs are available in Maven).
There is also more that needs to be done. If you create tickets to fix areas
that are lacking, it makes it easier for the community to address.
>
>13. I would suggest that Rave hosts its own site (Eating your own dog food)
>using rave itself along with samples
>
>I hope some of all of these things are on your agenda and hope you can get
>back to me when you have time. We (my company) are wiling to contribute to
>this excellent project if need be.
We would love you to contribute; whether it is just to discussions or via code
contributions. In general, I think you have some great points and ideas that
would make Rave easier to build on. I would recommend initiating separate
discussions for the big ones, or even better, providing patches that
demonstrate what you are looking for. This will drive the community to produce
the best possible outcome.
[1] http://wrangl.com/sass-v-less
>
>Cheers,
>Jose
