Nabble - NanoContainer - PicoContainer - Dev

picocontainer.org/web/preview/remoting.html - comments please :)

2008-12-30T07:45:51Z

picocontainer.org/web/preview/remoting.html

It's a preview of the doco on PWR.

- Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Merry Christmas All!

2008-12-26T06:27:58Z

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/

--- On Fri, 12/26/08, Jörg Schaible <joerg.schaible@...> wrote:

> From: Jörg Schaible <joerg.schaible@...>
> Subject: Re: [picocontainer-dev] Merry Christmas All!
> To: dev@...
> Date: Friday, December 26, 2008, 4:12 PM
> Mauro Talevi wrote:
>
> > Michael Rimov wrote:
> >> While I've been pretty silent the past month
> or two, I wanted to make
> >> sure you all were wished a Merry Christmas (and
> Boxing Day too :) )
> >>
> >> And a Happy New Year :)
> >>
> >>
> >
> > Buon Natale e Felice Anno Nuovo :-)
>
> Na dann: Euch allen gesegnete Weihnachten und ein frohes
> neues Jahr :))

С рождеством христовым , и веселого нового года ;)

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Merry Christmas All!

2008-12-26T06:12:50Z

Mauro Talevi wrote:

> Michael Rimov wrote:
>> While I've been pretty silent the past month or two, I wanted to make
>> sure you all were wished a Merry Christmas (and Boxing Day too :) )
>>
>> And a Happy New Year :)
>>
>>
>
> Buon Natale e Felice Anno Nuovo :-)

Na dann: Euch allen gesegnete Weihnachten und ein frohes neues Jahr :))

- Jörg

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Merry Christmas All!

2008-12-26T01:53:07Z

Michael Rimov wrote:
> While I've been pretty silent the past month or two, I wanted to make sure you
> all were wished a Merry Christmas (and Boxing Day too :) )
>
> And a Happy New Year :)
>
>

Buon Natale e Felice Anno Nuovo :-)

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Merry Christmas All!

2008-12-25T07:13:44Z

Right back at you Mike and gang :-)

Regards,

- Paul

On Dec 24, 2008, at 11:55 AM, Michael Rimov wrote:

> While I've been pretty silent the past month or two, I wanted to
> make sure you
> all were wished a Merry Christmas (and Boxing Day too :) )
>
> And a Happy New Year :)
>
>
> -Mike
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Merry Christmas All!

2008-12-24T11:55:51Z

While I've been pretty silent the past month or two, I wanted to make sure you
all were wished a Merry Christmas (and Boxing Day too :) )

And a Happy New Year :)

-Mike

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: PicoContainer 2.7 + releases for script, Jetty, and web ?

2008-12-23T11:43:31Z

Paul Hammant wrote:

> Folks,
>
> PicoWebRemoting has pushed forward most, but others have enough to
> warrant a release. Can I publish PicoContainer 2.7 and other packages
> in the next couple of days ?

Go with it ...

- Jörg

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: PicoContainer 2.7 + releases for script, Jetty, and web ?

2008-12-22T01:29:49Z

+1

Paul Hammant wrote:

> Folks,
>
> PicoWebRemoting has pushed forward most, but others have enough to
> warrant a release. Can I publish PicoContainer 2.7 and other packages
> in the next couple of days ?
>
> Regards,
>
> - Paul
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

PicoContainer 2.7 + releases for script, Jetty, and web ?

2008-12-21T15:32:36Z

Folks,

PicoWebRemoting has pushed forward most, but others have enough to
warrant a release. Can I publish PicoContainer 2.7 and other packages
in the next couple of days ?

Regards,

- Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: The constant web design wall I keep hitting [long]

2008-11-22T10:52:23Z

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/

--- On Sat, 11/22/08, Daniel Wellman <etldan@...> wrote:

> From: Daniel Wellman <etldan@...>
> Subject: Re: [picocontainer-dev] The constant web design wall I keep hitting [long]
> To: dev@...
> Date: Saturday, November 22, 2008, 4:50 PM
> I'm experiencing the same issue as Mike: we used
> PicoContainer 1.x and
> NanoContainer to build our WebWork 2 webapp. Our DAOs
> accept a
> request-scope Hibernate Session object, which we've
> wrapped with an
> implementation that implements the Pico Startable
> interface. On start() we
> get the session from the HibernateSessionFactory, and on
> stop() we close the
> Session. We use this to implement the Open Session in View
> pattern in our
> webapp, since we wrap the Pico Request Listener around our
> WebWork action
> servlet.
>
> It looks like PicoContainer 2 Persistence allows both
> strategies; the
> documentation suggests passing a HibernateSessionFactory to
> every DAO --
> HibernatePersister takes a SessionFactory parameter, and
> the app registers
> both ConstructableAnnotationConfiguration and
> ConfigurableSessionFactory:
>
> http://picocontainer.org/persistence/hibernate.html
>
> But then how do you implement the Open Session in View with
> this pattern?
> Don't you need to stop the Session at the end of every
> request?
>
> Thanks,
> Dan

I must disagree with this document ;) My DAOs always receive
session and do not care where it came from.
Hibernate configuration and session factory go into application
scope, and constructable session & DAOs go into request scope.
( or even some deeper subscope defined by container chain )

regards,

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: The constant web design wall I keep hitting [long]

2008-11-22T06:50:10Z

I'm experiencing the same issue as Mike: we used PicoContainer 1.x and NanoContainer to build our WebWork 2 webapp. Our DAOs accept a request-scope Hibernate Session object, which we've wrapped with an implementation that implements the Pico Startable interface. On start() we get the session from the HibernateSessionFactory, and on stop() we close the Session. We use this to implement the Open Session in View pattern in our webapp, since we wrap the Pico Request Listener around our WebWork action servlet.

It looks like PicoContainer 2 Persistence allows both strategies; the documentation suggests passing a HibernateSessionFactory to every DAO -- HibernatePersister takes a SessionFactory parameter, and the app registers both ConstructableAnnotationConfiguration and ConfigurableSessionFactory:

http://picocontainer.org/persistence/hibernate.html

But then how do you implement the Open Session in View with this pattern? Don't you need to stop the Session at the end of every request?

Thanks,
Dan

Paul Hammant-3 wrote:

hibernate and DAO stuff should definitely be in app scope (standard
picocontainer + caching)

Take a look at http://svn.codehaus.org/picocontainer/java/2.x/trunk/web/examples/struts2-webapp/
and the WebappComposer class for it - http://svn.codehaus.org/picocontainer/java/2.x/trunk/web/examples/web-example/src/java/org/picocontainer/web/sample/ExampleWebappComposer.java

The DAO is at app level. There is a DefaultCheeseService is at session
level for the example, but could as easily be in app scope. Requests
scope things like "AddCheese" "RemoveCheese" are added laziily later

Re: Pico Web Remoting + demo app - nearly finished.

2008-11-19T15:21:20Z

Paul Hammant wrote:
> Hi folks,
>
> I'm pretty pleased with PWR + the demo app. Its ready for anyone from
> the gang to step in and offer observations + fixups :-)
>
> Build PicoContainer first, the web-core, then web-remoting, then the
> jquery demo itself.
>

Or simply use use the snapshots deployed in

http://snapshots.repository.codehaus.org

Do note that this requires using the codehaus profile, as defined in

http://svn.codehaus.org/picocontainer/java/2.x/trunk/pico/distribution/src/config/settings.xml

Cheers

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Pico Web Remoting + demo app - nearly finished.

2008-11-19T01:42:54Z

Hi folks,

I'm pretty pleased with PWR + the demo app. Its ready for anyone from
the gang to step in and offer observations + fixups :-)

Build PicoContainer first, the web-core, then web-remoting, then the
jquery demo itself.

- Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Pico Web Remoting - status and small features folks could grab if have the time

2008-11-09T07:19:51Z

Paul Hammant wrote:

> Well the demo works well. IBM had it as a JSP app with some AJAX
> features. JSP has been eliminated - it's a one static page solution
> now, with lots of JSON via PicoWebRemoting.
>
>
>
>
> There are some things yet to be done, that others who are interested in,
> might want to join in with.
> Y'all know that everything I do need to be scrutinized in case something
> needs renaming :-)
>
> http://jira.codehaus.org/browse/PICO-332
> http://jira.codehaus.org/browse/PICO-333
> http://jira.codehaus.org/browse/PICO-334
> http://jira.codehaus.org/browse/PICO-335
> http://jira.codehaus.org/browse/PICO-336
> http://jira.codehaus.org/browse/PICO-337
> http://jira.codehaus.org/browse/PICO-338
> http://jira.codehaus.org/browse/PICO-339
>
> - Paul
>
>

Hi Paul

I think the concept is interesting and there is a space for this sort of
component. But I think the test cases need to be expressed better to
reflect what is the intended aim.

I would also refactor out the XStream dependency behind an interface
that is more expressive of the JSON functionality design - and have
XStream with the JSON driver as the default impl.

We can pair on it if you want.

Cheers

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Pico Web Remoting - status and small features folks could grab if have the time

2008-11-06T08:53:27Z

Well the demo works well. IBM had it as a JSP app with some AJAX
features. JSP has been eliminated - it's a one static page solution
now, with lots of JSON via PicoWebRemoting.

There are some things yet to be done, that others who are interested
in, might want to join in with.
Y'all know that everything I do need to be scrutinized in case
something needs renaming :-)

http://jira.codehaus.org/browse/PICO-332
http://jira.codehaus.org/browse/PICO-333
http://jira.codehaus.org/browse/PICO-334
http://jira.codehaus.org/browse/PICO-335
http://jira.codehaus.org/browse/PICO-336
http://jira.codehaus.org/browse/PICO-337
http://jira.codehaus.org/browse/PICO-338
http://jira.codehaus.org/browse/PICO-339

- Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

pastedGraphic.tiff (169K) Download Attachment

Progress on PicoWebRemoting

2008-11-03T08:40:40Z

( for the jquery webapp )

Access http://localhost:8080/remoting-jqueryemail-webapp/pwr/Mailbox and see -

{"methods":{"string":["send","pete","delete","read","messages"]}}

Access http://localhost:8080/remoting-jqueryemail-webapp/pwr/Mailbox/read and see -

HTTP ERROR: 400
Parameter 0 of 'public java.lang.Object org.picocontainer.web.sample.jqueryemailui.Mailbox.read(java.lang.String,java.lang.String)' cannot be null
RequestURI=/remoting-jqueryemail-webapp/pwr/Mailbox/read

Access http://localhost:8080/remoting-jqueryemail-webapp/pwr/Mailbox/read?msgId=1&view=inbox and see -

{"MessageData":{"id":1,"from":"J Query","to":"Gil Bates","subject":"Nice Example","message":"Very nice example application you've created","sentTime":"2008-11-03 08:33:25.193 PST","read":true}}

The app could be cut over from the home-grown JSON that it has now, to a PWR provided one.

I paired with Pete on Sunday, to talk through the features.

The composition is a little bit verbose when you're mapping query-string params to method parameters :- http://svn.codehaus.org/picocontainer/java/2.x/trunk/web/examples/jquery-email/src/java/org/picocontainer/web/sample/jqueryemailui/JQueryWebappComposer.java

Thoughts?

- Paul

Re: PicoCall : "every object has a URL"

2008-10-31T09:08:05Z

I've renamed it to PicoWebRemoting and pushed into Svn the JQuery demo
(as a starting point) :

https://svn.codehaus.org/picocontainer/java/2.x/trunk/web/examples/pwr/jquery_email_ui

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: PicoCall : "every object has a URL"

2008-10-31T07:56:16Z

Correction :- its an IBM example - http://www.ibm.com/developerworks/web/library/wa-jquery1

With some Ts & Cs :

> By selecting "I Accept Terms and Conditions" below, You acknowledge
> and agree that You have read and understand this Agreement and
> hereby expressly agree with, accept and consent to, its terms and
> conditions and to comply with all applicable laws and regulations,
> including export and re-export control laws and regulations. You
> further agree to all additional requirements and guidelines posted
> on the Website for this program. Furthermore, You hereby waive any
> claim or right that You may have to assert that Your electronic
> acceptance herewith is not the equivalent of, or deemed as, a valid
> signature to this Agreement.
>
> [ Click ]
>
> If you do not accept this license, please click on the BACK button
> on your browser
> Downloader Agreement
>
> The following are terms of a legal downloader agreement (the
> "Agreement") regarding Your download of Content (as defined below)
> from this Website. IBM may change these terms of use and other
> requirements and guidelines for use of this Website at its sole
> discretion. This Website may contain other proprietary notices and
> copyright information the terms of which must be observed and
> followed. Any use of the Content in violation of this Agreement is
> strictly prohibited.
>
> "Content" includes, but is not limited to, software, text and/or
> speech files, code, associated materials, media and /or
> documentation that You download from this Website. The Content may
> be provided by IBM or third-parties. IBM Content is owned by IBM and
> is copyrighted and licensed, not sold. Third-party Content is owned
> by its respective owner and is licensed by the third party directly
> to You. IBM's decision to permit posting of third-party Content does
> not constitute an express or implied license from IBM to You or a
> recommendation or endorsement by IBM of any particular product,
> service, company or technology.
>
> The party providing the Content (the "Provider") grants You a
> nonexclusive, worldwide, irrevocable, royalty-free, copyright
> license to edit, copy, reproduce, publish, publicly display and/or
> perform, format, modify and/or make derivative works of, translate,
> re-arrange, and distribute the Content or any portions thereof and
> to sublicense any or all such rights and to permit sublicensees to
> further sublicense such rights, for both commercial and non-
> commercial use, provided You abide by the terms of this Agreement.
> You understand that no assurances are provided that the Content does
> not infringe the intellectual property rights of any other entity.
> Neither IBM nor the provider of the Content grants a patent license
> of any kind, whether expressed or implied or by estoppel. As a
> condition of exercising the rights and licenses granted under this
> Agreement, You assume sole responsibility to obtain any other
> intellectual property rights needed.
>
> The Provider of the Content is the party that submitted the Content
> for Posting and who represents and warrants that they own all of the
> Content, (or have obtained all written releases, authorizations and
> licenses from any other owner(s) necessary to grant IBM and
> downloaders this license with respect to portions of the Content not
> owned by the Provider). All information provided on or through this
> Website may be changed or updated without notice. You understand
> that IBM has no obligation to check information and /or Content on
> the Website and that the information and/or Content provided on this
> Web site may contain technical inaccuracies or typographical errors.
>
> IBM may, in its sole discretion, discontinue the Website, any
> service provided on or through the Website, as well as limit or
> discontinue access to any Content posted on the Website for any
> reason without notice. IBM may terminate this Agreement and Your
> rights to access, use and download Content from the Website at any
> time, with or without cause, immediately and without notice.
>
> ALL INFORMATION AND CONTENT IS PROVIDED ON AN "AS IS" BASIS. IBM
> MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED,
> CONCERNING USE OF THE WEBSITE, THE CONTENT, OR THE COMPLETENESS OR
> ACCURACY OF THE CONTENT OR INFORMATION OBTAINED FROM THE WEBSITE.
> IBM SPECIFICALLY DISCLAIMS ALL WARRANTIES WITH REGARD TO THE IMPLIED
> WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A
> PARTICULAR PURPOSE. IBM DOES NOT WARRANT UNINTERRUPTED OR ERROR-FREE
> OPERATION OF ANY CONTENT. IBM IS NOT RESPONSIBLE FOR THE RESULTS
> OBTAINED FROM THE USE OF THE CONTENT OR INFORMATION OBTAINED FROM
> THE WEBSITE.
>
> LIMITATION OF LIABILITY. IN NO EVENT WILL IBM BE LIABLE TO ANY PARTY
> FOR ANY DIRECT, INDIRECT, SPECIAL OR OTHER CONSEQUENTIAL DAMAGES FOR
> ANY USE OF THIS WEBSITE, THE USE OF CONTENT FROM THIS WEBSITE, OR ON
> ANY OTHER HYPER LINKED WEB SITE, INCLUDING, WITHOUT LIMITATION, ANY
> LOST PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR OTHER DATA
> ON YOUR INFORMATION HANDLING SYSTEM OR OTHERWISE, EVEN IF IBM IS
> EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
>
> The laws of the State of New York, USA govern this Agreement,
> without reference to conflict of law principles. The "United Nations
> Convention on International Sale of Goods" does not apply. This
> Agreement may not be assigned by You. The parties agree to waive
> their right to a trial by jury.
>
> This Agreement is the complete and exclusive agreement between the
> parties and supersedes all prior agreements, oral or written, and
> all other communications relating to the subject matter hereof. For
> clarification, it is understood and You agree, that any additional
> agreement or license terms that may accompany the Content is
> invalid, void, and non-enforceable to any downloader of this Content
> including IBM.
>
> If any section of this Agreement is found by competent authority to
> be invalid, illegal or unenforceable in any respect for any reason,
> the validity, legality and enforceability of any such section in
> every other respect and the remainder of this Agreement shall
> continue in effect.
>

Regards,

- Paul

On Oct 31, 2008, at 7:10 AM, Paul Hammant wrote:

> There's one that comes with JQuery that looks simple. The server
> side should amount to a significant code reduction with PicoCall.
>
> <pastedGraphic.tiff>
>
>
> DWR had one too that was nice. Perhaps aesthetically more pleasing,
> but there were too many utility js classes from DWR in play, so it
> would not have been a fully ex-DWR copy.
> JQuery works nicer for us, because it says nothing about the server
> side, while providing neat JSON .get and .post functions.
>
> - Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

c.gif (62 bytes) Download Attachment
c.gif (62 bytes) Download Attachment

Re: PicoCall : "every object has a URL"

2008-10-31T07:10:05Z

There's one that comes with JQuery that looks simple. The server side
should amount to a significant code reduction with PicoCall.

DWR had one too that was nice. Perhaps aesthetically more pleasing,
but there were too many utility js classes from DWR in play, so it
would not have been a fully ex-DWR copy.
JQuery works nicer for us, because it says nothing about the server
side, while providing neat JSON .get and .post functions.

- Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

pastedGraphic.tiff (131K) Download Attachment

Re: PicoCall : "every object has a URL"

2008-10-30T15:12:01Z

Yeah, I'd love to pair on this :)

Its not new of course, as DWR is in the same territory...

Regards,

- Paul

On Oct 30, 2008, at 2:36 PM, peter royal wrote:

> On Oct 30, 2008, at 10:59 AM, Michael Rimov wrote:
>> In short, it appears that simply setting the data type to JSON will
>> net you a converted javascript object once the AJAX request is
>> complete.
>
> yah, generally.
>
> there's also http://docs.jquery.com/Ajax/jQuery.getJSON, which is a
> tad more explicit.
>
> paul, as far as a demo you can fork.. i don't know of any that are
> more app-like.
>
> but you can definitely take that Dojo link and just replace it with
> jquery. the dojo.io.Bind is $.getJSON (obviously lots of hand-waving
> going on here.. but its a fairly simple modification. we should do
> it over beer :)
>
> -pete
>
> --
> (peter.royal|osi)@pobox.com - http://fotap.org/~osi
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: PicoCall : "every object has a URL"

2008-10-30T14:36:09Z

On Oct 30, 2008, at 10:59 AM, Michael Rimov wrote:
> In short, it appears that simply setting the data type to JSON will
> net you a converted javascript object once the AJAX request is
> complete.

yah, generally.

there's also http://docs.jquery.com/Ajax/jQuery.getJSON, which is a
tad more explicit.

paul, as far as a demo you can fork.. i don't know of any that are
more app-like.

but you can definitely take that Dojo link and just replace it with
jquery. the dojo.io.Bind is $.getJSON (obviously lots of hand-waving
going on here.. but its a fairly simple modification. we should do it
over beer :)

-pete

--
(peter.royal|osi)@pobox.com - http://fotap.org/~osi

smime.p7s (3K) Download Attachment

RE: PicoCall : "every object has a URL"

2008-10-30T10:59:46Z

Sorry, I usually use HTML fragments when dealing with AJAX calls personally, so I haven’t been using JSON as the transport.

Here’s some pages that seem relevant, but not tested:

http://docs.jquery.com/Ajax

http://encosia.com/2008/05/29/using-jquery-to-directly-call-aspnet-ajax-page-methods/

In short, it appears that simply setting the data type to JSON will net you a converted javascript object once the AJAX request is complete.

That’s what I get for jumping into the middle of a conversation , but I hope it helps :)

Peter?

-Mike

From: Paul Hammant [mailto:paul@...]
Sent: Thursday, October 30, 2008 10:10 AM
To: dev@...
Subject: Re: [picocontainer-dev] PicoCall : "every object has a URL"

I need an existing JQuery/JSON demo to fork then.... none of these look like that ( http://ui.jquery.com/demos )

Can you point to anything I could start with ?

- Paul

On Oct 30, 2008, at 9:57 AM, Michael Rimov wrote:

I second Peter’s vote for JQuery.

http://jquery.com/

http://ui.jquery.com/

Ultra-Cool selection syntax, super fast benchmarks, and not all the bloat of Prototype/Scriptaculous.

-Mike

On Oct 30, 2008, at 8:14 AM, Paul Hammant wrote:

1) Does anyone think I should concentrate on something other than Dojo?

Re: PicoCall : "every object has a URL"

2008-10-30T10:09:56Z

I need an existing JQuery/JSON demo to fork then.... none of these look like that ( http://ui.jquery.com/demos )

Can you point to anything I could start with ?

- Paul

On Oct 30, 2008, at 9:57 AM, Michael Rimov wrote:

I second Peter’s vote for JQuery.

http://jquery.com/
http://ui.jquery.com/

Ultra-Cool selection syntax, super fast benchmarks, and not all the bloat of Prototype/Scriptaculous.

-Mike

On Oct 30, 2008, at 8:14 AM, Paul Hammant wrote:
1) Does anyone think I should concentrate on something other than Dojo?

RE: PicoCall : "every object has a URL"

2008-10-30T09:57:16Z

I second Peter’s vote for JQuery.

http://jquery.com/

http://ui.jquery.com/

Ultra-Cool selection syntax, super fast benchmarks, and not all the bloat of Prototype/Scriptaculous.

-Mike

On Oct 30, 2008, at 8:14 AM, Paul Hammant wrote:

1) Does anyone think I should concentrate on something other than Dojo?

Re: PicoCall : "every object has a URL"

2008-10-30T09:19:48Z

Where's the best example of a JQuery/JSON app dude ?

- Paul

On Oct 30, 2008, at 9:07 AM, peter royal wrote:

On Oct 30, 2008, at 8:14 AM, Paul Hammant wrote:
1) Does anyone think I should concentrate on something other than Dojo?

jquery

-pete

--

(peter.royal|osi)@pobox.com - http://fotap.org/~osi

Re: PicoCall : "every object has a URL"

2008-10-30T09:07:30Z

On Oct 30, 2008, at 8:14 AM, Paul Hammant wrote:

1) Does anyone think I should concentrate on something other than Dojo?

jquery

-pete

(peter.royal|osi)@pobox.com - http://fotap.org/~osi

smime.p7s (3K) Download Attachment

PicoCall : "every object has a URL"

2008-10-30T08:14:11Z

This is going to suit "thin server" webapps most. And I'm thinking Dojo looks to be elegant/simple in respect of that.

If a webapp's JS would do an XHR in this style ...

http://localhost:8080/picocall-webapp/some/package/structure/Cart/addTo?make=ford&model=focus

... the following JSON will result ....

    {"result":true}

Obviously, Authentication & Authorisation are still applicable, so universal access to objects method's directly is not a security concern.

For 'Example 2' from http://today.java.net/pub/a/today/2006/04/27/building-ajax-with-dojo-and-json.html

There's a Dojo web app that issues XHR requests to a JSP page to get back JSON result

http://localhost:8080/dojo_json/actions/book.jsp?bookId=1

{"bookId":1,"title":"Crime and Punishment","isbn":"0679734503","author":"Fyodor Dostoevsky"}

There's a zip containig a built that makes a war file that's quite easy. I'm thinking of copying that app our Svn and converting it to be a PicoCall managed thing.

Questions for the gang.

1) Does anyone think I should concentrate on something other than Dojo?

2) Is there a better publically available example to fork ?

- Paul

Re: Providers

2008-10-22T09:25:00Z

>
> At first when I read your design of Chocolatier in the test case, I
> thought...
> "Why do this when we have Behaviors in the first place???".... Then
> when I hit
> Chocolatier2, I finally realized where you were going with it and
> thought ...
> "Way cool" :)
>
> Thoughts:
> --How do you consider using a marker interface vs an annotation. ie:
>
> @Provider
> public class MyProvider {
>
> }
>
> vs
>
> public class MyProvider implements Provider {
>
> }
>

Its a good thought. The way it is now (with no methods) it fits an
annotation better.

> ?
>
> --I think the thing I like most about it is that it allows people to
> create
> Factory objects without deep knowledge of the inner workings of
> PicoContainer
> like Custom ComponentAdapters require.
>
> --I don't think its fringe... I think it is far more accessible to
> developers
> for providing custom ways of getting at your components. For example:
>
> public class JNDILookupProvider<T> implements Provider {
>
> public JNDILookupProvider(String contextPath) {
> /* ex contextPath = ' java:comp/env/jdbc/default' */
> };
>
> public <T> provide(IntialContext ctx) {
> /*Perform lookup on initialContext using contextPath*/
> return T;
> }
> }
>
> Nice and simple (if you can ever call JNDI lookups 'simple'! :) )...
> and the
> build of the container is logical:
>

maybe nice, but I'm not sure if the ProviderAdapter.getProvideMethod()
(and key determination) will work with that. I think return's can be
generic specified, but subclasses may compile that out of course.

> import javax.mail.Session;
>
> container.as(NO_CACHE).addComponent(InitialContext.class)
> .addAdapter(Session.class, new ProviderAdapter(new
> JNDILookupProvider<Session>("java:comp/env/mail/default"));
>
>
> Although from a usability standpoint, it would be nicer to have
>
> container.as(NO_CACHE).addComponent(InitialContext.class)
> .addComponent(Session.class, new
> JNDILookupProvider<Session>("java:comp/env/mail/default"));

or

container.as(NO_CACHE).addComponent(InitialContext.class)
.addAdapter(new JNDILookupProvider<Session>("java:comp/env/mail/
default"));

where Session is pulled from the generic type to become the key also ?

>
>
> and like instance registrations, have provider registrations wrapped
> in the
> appropriate adapter.
>
> Or possibly even delayed instantiation of the provider:
>
> container.as(NO_CACHE).addComponent(InitialContext.class)
> .addComponent(Session.class, new JNDILookupProvider.class, new
> ConstantParameter("java:comp/env/mail/default"));
>

maybe.

>
>
> Opposing thoughts: (Or as Tevya would say: "On the other hand...")
>
> --But just as ComponentAdapters have gotten more complicated over
> the years to
> handle specific use cases, is Provider too simple? For example, does
> it need
> lifecycle events? I'd personally hate to destroy the simplicity to
> handle those
> additional use cases.
>

I consider it niche to be honest. And for webapps is that niche.
Imagine a queryString param like so '?make=nike'. What if an action
wanted to depend on that (we're imagining a non-webwork, non-struts,
non-waffle web app).

public class Make {
private String name;
public Make(String name) {
this.name = name;
}
public String getName() {
return name;
}
}

public class Cart {
public boolean addTo(Make make, Model model, int quantity) {
// etc
}
}

public class CartFromRequest extends ProviderAdapter {
public Cart provide(HttpServletRequest req) {
return new Cart(req.getParameter("brandName"));
}
}

or better still. A parent class that could handle request params and :

pico.as(NO_CACHE).addAdapter(new FromRequest(Make.class, "make"));

more later.

> --Is there too much overlap between Providers and ComponentAdapters
> in the first
> place? After all, in the past, if I needed a custom provider, I
> just made a new
> ComponentAdapter. (Or even a custom ComponentParameter!). In fact,
> code base
> has JNDIComponentParameter, and I have in my own code a JNDIParameter:
>
> container.addComponent(EmailService.class,
> EmailService.class,
> new
> JNDIParameter("java:comp/env/mail/default"));
>
> So do we need yet another way to instantiate a component?
>
> Just thoughts :)
>
>
> -Mike
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

RE: Providers

2008-10-22T09:00:53Z

> My Guice buddies are divided on whether their providers feature is
> mainstream or niche. It allows you to have a factory that can help
> make deps on a just in time basis (for the particular scope) for other
> components to use.
>
> The interface goes like so :
>
> interface Provider<T> {\
> T get();
> }
>
> For Pico, as of a commit yesterday, we have a provider too. It's a
> little different. It's less generic than the Guice one :
>
> interface Provider {
> }
>
> It's a convention idiom. Have one method provide that returns the type
> you're interested in providing, but have as many concrete arguments
> for that method as you require. As long as those deps can be satisfied
> by the PicoContainer instance that is managing it, then it'll be fine.
>
> Have a look at Chocolatier and Chocolatier2 in
> http://svn.codehaus.org/picocontainer/java/2.x/trunk/pico/container/src/tes
> t/org/picocontainer/injectors/ProviderTestCase.java
> (yes there are two ways of working with Providers).

At first when I read your design of Chocolatier in the test case, I thought...
"Why do this when we have Behaviors in the first place???".... Then when I hit
Chocolatier2, I finally realized where you were going with it and thought ...
"Way cool" :)

Thoughts:
--How do you consider using a marker interface vs an annotation. ie:

@Provider
public class MyProvider {

}

vs

public class MyProvider implements Provider {

}

?

--I think the thing I like most about it is that it allows people to create
Factory objects without deep knowledge of the inner workings of PicoContainer
like Custom ComponentAdapters require.

--I don't think its fringe... I think it is far more accessible to developers
for providing custom ways of getting at your components. For example:

public class JNDILookupProvider<T> implements Provider {

public JNDILookupProvider(String contextPath) {
/* ex contextPath = ' java:comp/env/jdbc/default' */
};

public <T> provide(IntialContext ctx) {
/*Perform lookup on initialContext using contextPath*/
return T;
}
}

Nice and simple (if you can ever call JNDI lookups 'simple'! :) )... and the
build of the container is logical:

import javax.mail.Session;

container.as(NO_CACHE).addComponent(InitialContext.class)
.addAdapter(Session.class, new ProviderAdapter(new
JNDILookupProvider<Session>("java:comp/env/mail/default"));

Although from a usability standpoint, it would be nicer to have

container.as(NO_CACHE).addComponent(InitialContext.class)
.addComponent(Session.class, new
JNDILookupProvider<Session>("java:comp/env/mail/default"));

and like instance registrations, have provider registrations wrapped in the
appropriate adapter.

Or possibly even delayed instantiation of the provider:

container.as(NO_CACHE).addComponent(InitialContext.class)
.addComponent(Session.class, new JNDILookupProvider.class, new
ConstantParameter("java:comp/env/mail/default"));

Opposing thoughts: (Or as Tevya would say: "On the other hand...")

--But just as ComponentAdapters have gotten more complicated over the years to
handle specific use cases, is Provider too simple? For example, does it need
lifecycle events? I'd personally hate to destroy the simplicity to handle those
additional use cases.

--Is there too much overlap between Providers and ComponentAdapters in the first
place? After all, in the past, if I needed a custom provider, I just made a new
ComponentAdapter. (Or even a custom ComponentParameter!). In fact, code base
has JNDIComponentParameter, and I have in my own code a JNDIParameter:

container.addComponent(EmailService.class,
EmailService.class,
new
JNDIParameter("java:comp/env/mail/default"));

So do we need yet another way to instantiate a component?

Just thoughts :)

-Mike

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Providers

2008-10-22T07:54:56Z

Folks,

My Guice buddies are divided on whether their providers feature is
mainstream or niche. It allows you to have a factory that can help
make deps on a just in time basis (for the particular scope) for other
components to use.

The interface goes like so :

interface Provider<T> {\
T get();
}

For Pico, as of a commit yesterday, we have a provider too. It's a
little different. It's less generic than the Guice one :

interface Provider {
}

It's a convention idiom. Have one method provide that returns the type
you're interested in providing, but have as many concrete arguments
for that method as you require. As long as those deps can be satisfied
by the PicoContainer instance that is managing it, then it'll be fine.

Have a look at Chocolatier and Chocolatier2 in http://svn.codehaus.org/picocontainer/java/2.x/trunk/pico/container/src/test/org/picocontainer/injectors/ProviderTestCase.java
(yes there are two ways of working with Providers).

Thoughts?

Regards,

- Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email