Re: Shale home page
I plan to work on the home page, but I won't get much done until I get off the road for awhile, which will be in a couple of weeks. If not working on it, I've been thinking about the homepage lately, and it strikes me that I don't really know how to spin Shale. We have so many unrelated features that it's difficult to say "Shale is...". The addition of JPA makes things even murkier. Are we one-stop shopping for JSF? Proving ground for JSF 2.0? I know we're a set of services, but that's a rather bland description. david 2006/10/18, Craig McClanahan <[EMAIL PROTECTED]>: On 10/18/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > On 9/25/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > Someone on IRC brought up a good point about the Shale home page: We > > don't say what Shale *is* until 1/3 of the way down the page. > > > > I think the information in the paragraph that starts "Thus, Shale > > is..." belongs up at the top of the page. > > > > Thoughts? Volunteers to fix it? :) > > > > > We really need to do this. I plan to make some changes as time permits > (probably next week): > > * Remove logo bit from home page > * Move the historical out to its own page > * Try to add features-* pages content to the site sections of their > own modules (for example, the description in the dialog module site - > thanks Craig - is much more accurate and upto date that the > corresponding features page) > * Point to module sites rather than features-* where feasible > * Move download and documentation (which is really Javadocs) sections > to their own pages > * The mailing lists and issue tracking blurbs on home page can go > IMO, redundant given the LHS menu contains the links (need to add ML > link) Thanks Rahul ... +1 on all of these. One additional note on the "features" sections. With the way things are now spread out into submodules, I think we'll be able to completely get rid of these by the time we're done, because the information will have been distributed onto the submodule pages already. But, we'll also want to make sure that the submodule list is up to date in every website (IIRC it is manually maintained via cut-n-paste) to reflect the new additions. As for me, I'm planning on finishing up the main page for shale-dialog, and adding the rest of the stuff from features-dialog to the shale-dialog-basic page, in the next couple of days. And then some new content, hopefully soon. > > -Rahul Craig > -- > > Wendy > > >
Re: Shale home page
2006/9/25, Wendy Smoak <[EMAIL PROTECTED]>: Someone on IRC brought up a good point about the Shale home page: We don't say what Shale *is* until 1/3 of the way down the page. I think the information in the paragraph that starts "Thus, Shale is..." belongs up at the top of the page. Thoughts? Volunteers to fix it? :) Actually, IMO, that paragraph and the rest of the Background section are dated now that we've cut ties with Struts. We could probably do with a new introduction altogether. And a snazzy new logo, dammit. david -- Wendy
Re: Shale-related Tiles 2 issue
2006/9/24, Wendy Smoak <[EMAIL PROTECTED]>: On 9/24/06, David Geary <[EMAIL PROTECTED]> wrote: > 2006/9/24, David Geary <[EMAIL PROTECTED]>: > > > > 2006/9/24, Wendy Smoak <[EMAIL PROTECTED]>: > > > > > > On 9/24/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > > > > > Hey Wendy, this looks like the classic JSF 1.1 problem with JSP that > > > will > > > > be fixed in JSF 1.2. > > > > > > That's what I thought. :) > > > > > No, that's not the case. You must still use subviews in JSF 1.2. That's a > different issue than integration with JSP. What about the verbatim tags? I thought that was fixed in JSF 1.2. You don't need verbatim for JSF 1.2, but you do need subviews for included content. david -- Wendy
Re: Shale-related Tiles 2 issue
2006/9/24, David Geary <[EMAIL PROTECTED]>: 2006/9/24, Wendy Smoak <[EMAIL PROTECTED]>: > > On 9/24/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > > Hey Wendy, this looks like the classic JSF 1.1 problem with JSP that > will > > be fixed in JSF 1.2. > > That's what I thought. :) No, that's not the case. You must still use subviews in JSF 1.2. That's a different issue than integration with JSP. david It's also a good practice to wrap an included fragments in a subview > tag. The subview is a naming container that will allow the same fragment > containing input widgets to be included several times in the same page. > > > > > > > > > > This came up recently on [EMAIL PROTECTED] [1] and Dick Starr reported that > the was working with or without a subview tag. I'm not > sure how that differs from though. Anytime you include content with JSF you must wrap the included content in a subview (and you must manually assign the subview an id with the id attribute). I doubt he's including the header text more than once... exactly when > is the subview tag necessary, and what does it do? It's actually quite similar to Clay: it grafts a subview onto the main view. You always need it when you include content, whether you use or Tiles. btw, doesn't include content; it only gets the value of a tile attribute as a string. That's why it doesn't require a subview. david [1] > http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#a6288731 > > Thanks, > Wendy >
Re: Shale-related Tiles 2 issue
2006/9/24, Wendy Smoak <[EMAIL PROTECTED]>: On 9/24/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > Hey Wendy, this looks like the classic JSF 1.1 problem with JSP that will > be fixed in JSF 1.2. That's what I thought. :) > It's also a good practice to wrap an included fragments in a subview tag. The subview is a naming container that will allow the same fragment containing input widgets to be included several times in the same page. > > > > This came up recently on [EMAIL PROTECTED] [1] and Dick Starr reported that the was working with or without a subview tag. I'm not sure how that differs from though. Anytime you include content with JSF you must wrap the included content in a subview (and you must manually assign the subview an id with the id attribute). I doubt he's including the header text more than once... exactly when is the subview tag necessary, and what does it do? It's actually quite similar to Clay: it grafts a subview onto the main view. You always need it when you include content, whether you use or Tiles. btw, doesn't include content; it only gets the value of a tile attribute as a string. That's why it doesn't require a subview. david [1] http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#a6288731 Thanks, Wendy
Re: [ANNOUNCE] New Shale Committer: David Geary
Gee, thanks Wendy. I'm a bit choked up. 8-) david 2006/9/14, Wendy Smoak <[EMAIL PROTECTED]>: Please join us in welcoming David Geary as a new Shale committer. David was involved with Shale while it was a Struts sub-project, and suggested improvements to Shale Remoting, among other things. More recently, he has been working on documentation. Welcome back, David! -- Wendy
Re: [dialog] Revisiting one dialog per JSF view
2006/9/5, Sean Schofield <[EMAIL PROTECTED]>: We might want to revisit the one dialog per JSF view assumption. I'm playing with the new stuff in shale-petstore and I have run into some unexpected behavior. I have a commandLink that kicks off a "checkout" dialog. This command link is located in a "menu" bar that is displayed on every page using a facelets layout scheme (for those not familiar with facelets, the reusable layouts are similar to Tiles.) Lets suppose there are a few more "menu" options, such as logout, my account, etc. I've already made the argument that you should be able to "cancel" the dialog by clicking som other command link in the menu that has nothing to do with the dialog outcomes (SHALE-276). While this might be a PITA to support, its pretty common in a webapp to want to click on something else on the screen other then the previous, next buttons of your dialog. IMO, the expected behavior would be that the dialog stops and the new view is loaded. One way or another, we've got to support non-dialog outcomes during the course of a dialog. Halting the dialog seems to make sense, but of course, there will be users that link out of a dialog and then hit the back button expecting to be back in the dialog. david Sean
Re: [PROPOSAL] Open the Shale Sandbox to any interested Apache committer
+1 david 2006/9/1, Sean Schofield <[EMAIL PROTECTED]>: +1 On 9/1/06, Greg Reddin <[EMAIL PROTECTED]> wrote: > +1 > > On Aug 31, 2006, at 9:47 PM, Wendy Smoak wrote: > > > The Jakarta Commons sandbox is open [1] to any Apache committer who > > expresses an interest in working there, and the Maven developers are > > discussing [2] the addition of an open sandbox area for plugin > > development. > > > > I propose that we do the same, and open the Shale Sandbox to any > > existing Apache committer who would like to collaborate on > > Shale-related projects. > > > > [1] (I don't see the policy on the Commons Sandbox website, but I know > > I've seen it mentioned on the dev list.) > > [2] http://www.nabble.com/Maven-Sandbox-for-Apache-Committers- > > t2186725.html > > > > -- > > Wendy > > > >
Re: [dialog] Missing requirements?
It might be worthwhile to sufficiently generalize this so that it can be
used by applications that have their own config files.
david
2006/8/28, Gary VanMatre <[EMAIL PROTECTED]>:
>From: "Craig McClanahan" <[EMAIL PROTECTED]>
>
> On 8/28/06, Paul Spencer wrote:
> >
> > Should the following be added as a requirements:
> >
> > o A managed bean can be populated by one or more action and views
solely
> > via
> > configuration. The use of the dialog API by the user's application is
> > not needed.
> > Said another way, an existing JSF Bean and view, view.jsp, can be
> > broken up into
> > a dialog by configuring the dialog and breaking apart view.jsp into
> > many
> > jsp files.
> > (Currently this is possible when using session managed beans.)
>
>
> I'm not quite sure how to articulate this as a requirement. Woutd it be
> sufficient to say "You should be able to utilize the dialog
functionality
> WITHOUT being required to use the provided state storage mechanism (i.e.
#{
> dialog.data.foo}), as long as the application manages this state itself"
or
> something like that?. If so, I think that might be a reasonable
requirement
> to add -- although in practice I'm having a hard time figuring out how a
> dialog framework could make this NOT work.
>
> o Changes to the dialog configuration will not require a restart of the
> > application
> > in order to take affect. (Currently the servlet engine must be
> > restarted or the
> > web application must be reloaded for changes to dialog-config.xml to
> > take affect.)
>
>
> Makes sense ... and it should apply to any and all configuration files,
not
> just the dialog one. I think Clay has a mechanism for this already that
we
> should be able to reuse.
>
Clay's file reload mechanism is wired into the ComponentConfigBean as an
inner class called WatchDog.
http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/beans/ComponentConfigBean.java?view=markup
A group or single file is defined by a logical name. If one of the files
in the group is dirty, the entire group is reloaded. You can also force a
reload. This is necessary if one group has a dependency with another
group. For example, in Clay, if a common config file is changed, all files
need to be reloaded since definitions in one file can extend definitions in
the commons config files. We might be able to abstract out with a couple
hooks you need to implement or register a callback adapter. Commons chains
might also work here.
The files are define using a top level interface. It could also be pulled
out.
http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/beans/ConfigBean.java?view=markup
It uses a preprocess filter command as the timer so there are not any
threads not controlled by the container.
http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/beans/ConfigDefinitionsWatchdogFilter.java?view=markup
> Paul Spencer
>
>
> Craig
Gary
Re: [dialog] How to use a common view with different dialog managed beans?
That's an interesting proposal. IIUC, this is kind of like Tomahawk's
aliasBean, but for Shale dialogs. You could achieve the same effect by
wrapping each of your view state jsp's with . Right?
If we were to incorporate something like this, I think we should:
1. Allow multiple es.
2. Like transitions, have global and state-scoped aliases. Aliases declared
within a state would be scoped to that state. Aliases declared outside any
view would be global to all views in the dialog.
I'm a big fan of . Reusing code for multiple managed beans is
very nice.
david
2006/8/25, Paul Spencer <[EMAIL PROTECTED]>:
Sean,
1) I am neither for nor against scrapping #{dialog.data}.
2) I am advocating a way of mapping an existing, or new managed bean, to
a dialog managed bean as a part of the dialog configuration.
As an example the following would create a dialog managed bean
named paymentBean that is an alias for the creditCard managed bean.
This allows the common view, /getBillingAddress.jsp, to use
#{paymentBean} which is really #{creditCard} or #{check} depending
on which dialog is being executed.
Paul Spencer
Sean Schofield wrote:
> I think Paul was commenting on an earlier idea that I had about
> scrapping #{dialog.data} in favor of a managed bean type solution. If
> I'm reading his message correctly he raises some good points. I think
> we're past that idea now though in favor of keeping #{dialog.data} but
> no longer blowing away the context when entering a subdialog.
>
> Sean
>
>
>
> On 8/25/06, Paul Spencer <[EMAIL PROTECTED]> wrote:
>
>> Rahul,
>> This was not a "how to do I do this" question. It was in reference to
>> the current Dialog Manager design effort.
>>
>> Paul Spencer
>>
>>
>> Rahul Akolkar wrote:
>> > On 8/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>> >
>> >> On 8/25/06, Paul Spencer <[EMAIL PROTECTED]> wrote:
>> >> >
>> >> > An advantage with the current dialog.data bean is that it allows
>> a the
>> >> > use of a common view when the underlying data objects are
different.
>> >> How
>> >> > would this be done with dialog managed beans?
>> >> >
>> >> >
>> >> > As an example the AbstractPayment class has a CreditCard and a
Check
>> >> > implementation. Both the "Pay By Check" and "Pay by CreditCard"
>> >> share a
>> >> > common view that collects the billing address information. In the
>> >> > current implementation, that view uses
>> #{dialog.data.billingZipCode} to
>> >> > pass the billing zip code regardless of the actual class. With
>> dialog
>> >> > managed beans their will be a check and creditCard bean so how
would
>> >> the
>> >> > billing zip code be referenced in the common view? So unless
their
>> >> is a
>> >> > way to alias the beans in the dialog configuration, the billing
>> address
>> >> > view can not be shared.
>> >>
>> >>
>> >> You are limited to a single instance of #{dialog.data}, but that
bean
>> >> itself
>> >> can have properties that are, in fact , beans ... and you can nest
as
>> >> deeply
>> >> as you like. So, your Payment class (the one you use as the data
bean
>> >> for
>> >> one of the processes could have a property of type AddressBean, and
>> you
>> >> could therefore have binding expressions like
>> >> "#{dialog.data.address.zipCode}"
>> >> to talk to it. The only collaboration that would be needed here is
>> >> that all
>> >> of the 'outer" data beans that used an AddressBean would need to
>> store it
>> >> under the same property name. You don't have to worry if the type
>> of the
>> >> "data" bean is different, because the EL machinery takes care of all
>> >> of that
>> >> for you.
>> >>
>> >
>> >
>> > And IIU your class diagram correctly, having the zip in the
>> > AbstractPayment automatically takes care of this. All you would then
>> > need to do is populate #{dialog.data} with either the CreditCard or
>> > the Check bean via the "setup" action state in the corresponding
>> > dialog.
>> >
>> > -Rahul
>> >
>> >
>> >> Paul Spencer
>> >> >
>> >>
>> >>
>> >>
>> >> Craig
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Re: [dialog] Get rid of subdialogs
2006/8/24, Sean Schofield <[EMAIL PROTECTED]>:
> I think the scope is useful, but I'm still not convinced the extra
> complexity required to support easy access of ancestral data on the
dialog
> stack is worth the effort. It seems to me that you can easily handle
> situations like this with setup actions that synthesize the right data
and
> make it available to the view via #{dialog.data}.
So we abandon #{dialog.data} and leave it as an "exercise for the
user" to supply their own mechanism for managing a "dialog scope"? Is
that what you're saying?
I'm not sure. I am somewhat uncomfortable adding new functionality when
there's already a valid mechanism in place, especially when such a change
requires considerable design changes. And in this case, we've got our hands
full of things that must be fixed for a viable dialog implementation that's
usable in production, such as supporting simultaneous dialogs. I'd rather
concentrate on those things first, hoping that the smaller issues, such as
this, will fall out in the design, if appropriate.
david
david
Sean
> > > david
> >
> > Sean
> >
>
>
Re: Review Core JSF coverage of Shale dialogs?
2006/8/24, Sean Schofield <[EMAIL PROTECTED]>: When's the book supposed to be published? As soon as reviewers provide feedback! For those who are anxious to learn JSF and can't wait for the 2nd edition, I suggest you get the first edition now! I wish I had it way back when I was first trying to understand JSF. I'm happy to review the whole book if you need a reviewer. Thanks for the kind words. I may take you up on your offer. david Sean On 8/24/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > >From: "David Geary" <[EMAIL PROTECTED]> > > > > Would anyone like to review material on Shale dialogs from the upcoming 2nd > > ed of Core JSF (about 15 pages)? I have an example with a Bill Pay dialog > > that has a Wire Transfer subdialog. The data entered into the subdialog is > > incorporated into the enclosing dialog's data, so it's pertinent to our > > current dialog discussion. > > > > I'd love to review this section or pretty much any chapter :--) > > > > > > david > > Gary >
Re: [dialog] Get rid of subdialogs
2006/8/24, Sean Schofield <[EMAIL PROTECTED]>:
> OTOH, I don't think this necessarily warrants a change to subdialog
design
> because dialogs have the mechanisms to deal with this. The starting
state
> for a subdialog can be an action state, and that method can set up the
> dialog.data reference before entering the first view state.
Its true you can always maintain dialog data outside of the dialog
mechanism by setting up your own session scoped bean in the starting
action state. If you do this, you bypass one of the supposed benefits
of dialog which is that it manages a state for you that lasts only
during the duration of the dialog.
Actually, I'm not using session-scoped beans and I am taking advantage of
dialog scope. Let me explain.
The benefit of dialog state is that views have reference to the state
through #{dialog.data}. In my setup actions, I assign instance variables
(they're not session scoped) to #{dialog.data}. No matter what view is
invoked, the correct data is always referenced through #{dialog.data}, so
I'm taking advantage of dialog scope.
IOW, Shale doesn't manage a state for you that lasts only during the
duration of the dialog; instead, it makes that state available to the view
via #{dialog.data} only during the duration of the dialog. How long the
state lasts is another matter.
To clarify things, here's some code. I've got a Bill Pay dialog with a Wire
Transfer subdialog.
In payment.xml, which defines the Bill Pay dialog:
...
...
Shale calls DialogLauncher.setupPaymentDialog() when you enter the dialog
and then transitions immediately to Payee Information.
Similarly in wireTransfer.xml:
...
Shale calls DialogLauncher.setupWireTransferDialog() when you enter the
dialog and then transitions immediately to Bank Information.
So I have two methods: setupPaymentDialog() and setupWireTransferDialog() in
DialogLauncher. Those methods assign the appropriate objects to dialog.data:
package com.corejsf.dialog;
import org.apache.shale.view.AbstractFacesBean;
import com.corejsf.dialog.data.BillpayData;
import com.corejsf.dialog.data.WireTransferData;
public class DialogLauncher extends AbstractFacesBean {
// billpayData contains all of the properties for the
// payment dialog. It also contains a couple of JSF
// action methods used for navigation, and an
// embedded wire transfer data object
private BillpayData billpayData = null;
// Called just afer entering the payment dialog
public String setupPaymentDialog() {
// Create billpay data and nested wire transfer data
billpayData = new BillpayData();
billpayData.setTransfer(new WireTransferData());
// Set dialog data with the handy setValue method
// from org.apache.shale.view.AbstractFacesBean
setValue("#{dialog.data}", billpayData);
// This outcome takes us to the payment dialog's
// first view
return "success";
}
// Called just afer entering the wire transfer dialog
public String setupWireTransferDialog() {
// Set the dialog's data to the wire transfer object
// stored in the bill pay data
setValue("#{dialog.data}", billpayData.getTransfer());
// This outcome takes us to the wire transfer dialog's
// first view
return "success";
}
}
I'm not 100% convinced such a dialog scope is that useful, but if you
are going to provide such a mechansim, you need to be able to *easily*
access it through the duration of the dialog and all subdialogs in the
chain. Right now the data is "popped" off the "stack" each time you
enter a subdialog so you can't use #{dialog.data} in your JSF to refer
to stuff from a previous page.
I think the scope is useful, but I'm still not convinced the extra
complexity required to support easy access of ancestral data on the dialog
stack is worth the effort. It seems to me that you can easily handle
situations like this with setup actions that synthesize the right data and
make it available to the view via #{dialog.data}.
david
> david
Sean
Review Core JSF coverage of Shale dialogs?
Would anyone like to review material on Shale dialogs from the upcoming 2nd ed of Core JSF (about 15 pages)? I have an example with a Bill Pay dialog that has a Wire Transfer subdialog. The data entered into the subdialog is incorporated into the enclosing dialog's data, so it's pertinent to our current dialog discussion. david
Re: [dialog] Get rid of subdialogs
I agree that it's often useful for a subdialog to access data contained in a parent dialog, or as SHALE-153 points out, vice-versa. Use cases where subdialogs are entirely self-contained would certainly seem to be in the minority. OTOH, I don't think this necessarily warrants a change to subdialog design because dialogs have the mechanisms to deal with this. The starting state for a subdialog can be an action state, and that method can set up the dialog.data reference before entering the first view state. What the dialog.data reference points to, and whether that object has access to the data object of the enclosing dialog (or vice-versa) seems like more of OO design issue that's separate from the dialogs themselves. david 2006/8/23, Sean Schofield <[EMAIL PROTECTED]>: I'm not quite convinced that is very useful as implemented. I see the usefulness in stringing existing dialogs together but certain byproducts of subdialog are undesirable. For instance, SHALE-153 which complains about how you can't easily access state information between a "parent" and "child" dialog. I've discussed this with Craig before and IIRC he doesn't agree with me on this but I can't see how having subdialogs as "black boxes" is very useful. Maybe there are some use cases out there but it would seem to me that its much more common that you would want to share state across two dialogs. Here's a hypothetical example: Suppose you have a e-commerce site where you sell both physical products as well as downloadable software. You have the following "dialogs": shopping cart shipping payment download link Each of these "dialogs" represents a series of actions and views. For the physical goods you might want to compose a "physical goods" dialog as follows: shopping cart -> shipping -> payment For the downloadable software you might want to compose a dialog that uses the same shopping cart and payment dialogs as in the physical goods case: shopping cart -> payment -> download link If you compose these using you immediately run into problems. Your payment dialog has no access to any of the state generated by the shopping cart phase of the dialog. As a developer I don't want shopping cart and payment to be black boxes, I want them to work seamlessly together. I also don't want to configure the shopping cart and payment stuff twice in order to avoid this. I think the ability to plug dialogs into one another is really cool but in the past I have found myself doing various hacks and workarounds to get at the state information further down the stack. Of course we could make it optional to create a new state for the subdialog but there are other reasons not to bother with this. I have implemented my own prev, next, ok button scheme on top of shale dialogs and subdialogs significantly complicate this. Sean
Re: [VOTE] Shale Version 1.0.3 Release
+1 david 2006/8/22, Matthias Wessendorf <[EMAIL PROTECTED]>: +1 On 8/21/06, Sean Schofield <[EMAIL PROTECTED]> wrote: > +1 (Binding) > > On 8/20/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > At long last :-), the bits are ready for a vote. All of the following files > > have md5 and sha1 checksums, and are in addition signed by my code signing > > key. They correspond to revision 433108 in the SVN repository, which I'm > > about to tag as APACHE_SHALE_1_0_3. > > > > > > (1) Maven Snapshot Repository At Apache: > > > > (http://people.apache.org/repo/m2-snapshot-repository) > > > > org.apache.shale.extras:mailreader-jpa:1.0.3 > > org.apache.shale:shale-apps-parent:1.0.3 > > org.apache.shale:shale-clay:1.0.3 > > org.apache.shale:shale-core:1.0.3 > > org.apache.shale:shale-dist:1.0.3 > > org.apache.shale:shale-parent:1.0.3 > > org.apache.shale:shale-remoting:1.0.3 > > org.apache.shale:shale-spring:1.0.3 > > org.apache.shale:shale-test:1.0.3 > > org.apache.shale:shale-tiger:1.0.3 > > org.apache.shale:shale-tiles:1.0.3 > > > > (If you have tested previous test builds of 1.0.3, you'll need to clear > > your local m2 repository to pick up these bits) > > > > (2) Release Artifacts > > > > (http://people.apache.org/~craigmcc/shale-proposed-release-1.0.3/) > > > > mailreader-jpa-1.0.3.zip > > shale-blank-1.0.3.zip > > shale-clay-usecases-1.0.3.zip > > shale-framework-1.0.3.zip > > shale-mailreader-1.0.3.zip > > shale-mailreader-jpa-1.0.3.zip > > shale-sql-browser-1.0.3.zip > > shale-usecases-1.0.3.zip > > > > (3) Vote > > > > Please review these artifacts, and test their signatures, then vote on > > whether we should release them as Apache Shale version 1.0.3. If it passes > > we'll hold a quality vote later on. > > > > [ ] +1 (Binding) for PMC members only > > [ ] +1 for community members who have reviewed the bits > > [ ] +0 > > [ ] -1 for fatal flaws that should cause these bits not to be released > > > > My vote is > > > > +1 (Binding) > > > > Craig McClanahan > > > > > -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: svn commit: r429947 - in /shale/framework/trunk/src/site: resources/images/remoting-001.jpg resources/images/remoting-002.jpg resources/images/remoting-003.jpg xdoc/features-remoting.xml
I've attached an updated features-remote.xml to SHALE-130 that contains the changes outlined below. Thanks, david 2006/8/9, David Geary < [EMAIL PROTECTED]>: Thanks for committing this, Wendy. It looks good. If you don't mind, could you add a couple of updates? Thanks. Please add these two paragraphs at the end of Remoting Introduction, after the bulleted list: Processors are associated with URL patterns. Each processor has a default pattern. For example, the Class Resource processor by default, is associated with the URL pattern /static/*, so any URL starting with static is handled by that processor. You can override those default patterns with context initialization parameters if you wish. That's a pretty abstract description of Shale remoting, so let's take a look at a concrete example of remotely calling managed bean methods. At the end of the An Ajax Example, just before Resources, please add this paragrah: The preceeding JavaScript stores the response text, which we generated in the userBean's validateUsername method. Because Shale calls the Faces context responseComplete() method, which halts the JSF lifecycle and therefore inhibits a page refresh, the updated DIV will be the only thing that changes on the page. Also, could you switch the Accessing Static Resources and Remotely Calling Managed Bean Methods? I think we get more bang for our buck if we open with the Ajax example. Thanks for all your help, david 2006/8/8, [EMAIL PROTECTED] < [EMAIL PROTECTED]>: > Author: wsmoak > Date: Tue Aug 8 20:24:32 2006 > New Revision: 429947 > > URL: http://svn.apache.org/viewvc?rev=429947&view=rev > Log: > Improve documentation for Shale Remoting. > Submitted By: David Geary > SHALE-130 > > Added: > shale/framework/trunk/src/site/resources/images/remoting-001.jpg > (with props) > shale/framework/trunk/src/site/resources/images/remoting-002.jpg > (with props) > shale/framework/trunk/src/site/resources/images/remoting-003.jpg > (with props) > Modified: > shale/framework/trunk/src/site/xdoc/features-remoting.xml [snip]
Re: svn commit: r429947 - in /shale/framework/trunk/src/site: resources/images/remoting-001.jpg resources/images/remoting-002.jpg resources/images/remoting-003.jpg xdoc/features-remoting.xml
Thanks for committing this, Wendy. It looks good. If you don't mind, could you add a couple of updates? Thanks. Please add these two paragraphs at the end of Remoting Introduction, after the bulleted list: Processors are associated with URL patterns. Each processor has a default pattern. For example, the Class Resource processor by default, is associated with the URL pattern /static/*, so any URL starting with static is handled by that processor. You can override those default patterns with context initialization parameters if you wish. That's a pretty abstract description of Shale remoting, so let's take a look at a concrete example of remotely calling managed bean methods. At the end of the An Ajax Example, just before Resources, please add this paragrah: The preceeding JavaScript stores the response text, which we generated in the userBean's validateUsername method. Because Shale calls the Faces context responseComplete() method, which halts the JSF lifecycle and therefore inhibits a page refresh, the updated DIV will be the only thing that changes on the page. Also, could you switch the Accessing Static Resources and Remotely Calling Managed Bean Methods? I think we get more bang for our buck if we open with the Ajax example. Thanks for all your help, david 2006/8/8, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: Author: wsmoak Date: Tue Aug 8 20:24:32 2006 New Revision: 429947 URL: http://svn.apache.org/viewvc?rev=429947&view=rev Log: Improve documentation for Shale Remoting. Submitted By: David Geary SHALE-130 Added: shale/framework/trunk/src/site/resources/images/remoting-001.jpg (with props) shale/framework/trunk/src/site/resources/images/remoting-002.jpg (with props) shale/framework/trunk/src/site/resources/images/remoting-003.jpg (with props) Modified: shale/framework/trunk/src/site/xdoc/features-remoting.xml [snip]
Re: Remoting Documentation
2006/8/8, Wendy Smoak <[EMAIL PROTECTED]>: On 8/8/06, David Geary <[EMAIL PROTECTED]> wrote: > There's still some work to be done on remoting documentation, but this > should get us 60%, or so, of the way there. I'm working with it now. Thanks. BTW, what error are you getting from 'mvn site' ? The build succeeds, but when I pull up .../shale-core/target/site/index.html, I get a page with very little content and missing links. david -- Wendy
Re: Remoting Documentation
2006/8/8, Wendy Smoak <[EMAIL PROTECTED]>: On 8/8/06, David Geary <[EMAIL PROTECTED]> wrote: > I've attached an HTML file that documents Shale Remoting. It would be nice > if some kind committer could drop it into > $SHALE_HOME/framework/trunk/src/site/xdoc/features-remoting.xml > and commit that XML file. I would've given you the XML file directly, but > 'mvn site' isn't exactly working for me at the moment. Thank you! I don't think the list accepts attachments. Can you open a JIRA issue and attach it there? There was already an issue: Shale-130. I attached a ZIP, but then realized that I needed to account for the bigger picture so I made some mods and attached a second ZIP file. So, there are two ZIP files attached to Shale-130. The 314kb version should be removed, but I don't have admin privileges. There's still some work to be done on remoting documentation, but this should get us 60%, or so, of the way there. Thanks, david http://issues.apache.org/struts/browse/SHALE -- Wendy
Re: Remoting Documentation
Will do. david 2006/8/8, Greg Reddin <[EMAIL PROTECTED]>: Attachment didn't seem to go through. Could you file a ticket? You can send me the file directly I'll still have to open a ticket to commit it. Greg On Aug 8, 2006, at 4:25 PM, David Geary wrote: > I've attached an HTML file that documents Shale Remoting. It would > be nice if some kind committer could drop it into $SHALE_HOME/ > framework/trunk/src/site/xdoc/features-remoting.xml and commit that > XML file. I would've given you the XML file directly, but 'mvn > site' isn't exactly working for me at the moment. > > Thanks, > > > david
Remoting Documentation
I've attached an HTML file that documents Shale Remoting. It would be nice if some kind committer could drop it into $SHALE_HOME/framework/trunk/src/site/xdoc/features-remoting.xml and commit that XML file. I would've given you the XML file directly, but 'mvn site' isn't exactly working for me at the moment. Thanks,david
Re: JSR-299 ("Web Beans") Implementation In Shale?
2006/7/27, Greg Reddin <[EMAIL PROTECTED]>: On Jul 27, 2006, at 2:55 PM, Craig McClanahan wrote: > What do you think? Are we interested in putting this on our > roadmap? (And > following up +1s with code? :-) +1. All I know about JSR-299 so far is that it is inspired by Seam. All I know about Seam is what I heard from Gavin's session at JavaOne, and I have to admit it was pretty compelling. Seam is very cool. I have a Seam CRUD demo in one of my NFJS sessions that's a big attention-getter. david Greg
Re: JSR-299 ("Web Beans") Implementation In Shale?
+1. I think it's a good--and exciting--fit for Shale. david 2006/7/27, Craig McClanahan <[EMAIL PROTECTED]>: I recently spoke with Gavin King (spec lead for JSR-299) about this JSR. In addition to getting his agreement on both Matthias and James to be on the EG, we talked a bit about their (Red Hat's) plans for the RI and TCK. Their thinking is that the RI and TCK would be developed by Red Hat themselves (since they are the company responsible for providing it) under some reasonable open source license ... but Gavin would actually like it if there was a second implementation being developed at the same time. That kind of thing goes a long way towards catching design limitations and/or ambiguities in the spec as it's being developed. So, I've got a question for us ... would we be interested (now or later) in building *a* compatible implementation of this JSR, even though it wouldn't be *the* RI? Instead, it would be a feature of Shale in addition to all the other stuff we do. I'm pretty intrigued by this, and the ideas that JSR-299 wants to deal with fit pretty nicely with what we've already started. It would make sense for us to have this kind of functionality available inside Shale. If we go this way, this seems like a good candidate for the sandbox during development (since we wouldn't be able to ship a finished release of it until the spec goes final). What do you think? Are we interested in putting this on our roadmap? (And following up +1s with code? :-) Craig PS: Another JSR we should keep an eye on is 303 (common annotations for validation) that Jason recently submitted. If it gets accepted, we'll likely want to support the result in Shale as well.
