sandler-develop Mailing List for sandler
Brought to you by:
intabulas
Menu
▾
▴
sandler-develop — Sandler Development
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
(4) |
Mar
(4) |
Apr
(6) |
May
(6) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mark L. <mar...@ca...> - 2005-02-02 14:52:13
|
As of two weeks ago I decided to put sandler out to pasture. I just don't have the time to keep up and with most of the inertia behind Rome I felt it was best to stop on Sandler and contribute to Rome.. Plus Blojsom takes most of my time See for more detail http://www.javaslash.org/blog/2005/01/18/pulling_sandlers_lifesupport.html NOTE: I do have it rev'd to the 04 draft but not the latest 05 draft M On 2/2/05 5:29 AM, "Benjamin Reitzammer" <fir...@us...> wrote: > Hello, > I'm currently developing an open source personal search engine > (roosster.org) in Java. I'm planning to build the whole input/output > format upon Atom, and now I'm looking for an Atom API implementation. > Sandler looks very good, and I've used it in the past already. > > I was wondering how the state of Sandler was, expecially when > considering the rather fast development of the Atom Format in the last > weeks. > Do you plan to adapt Sandler to these changes? When will this be? When > the Format is formally a IETF standard? > I just ask, because it seems as there was no Sandler development in the > last 6 months, and I don't want to base my project on a probably stalled > project. > > Thanks for your help > > Benjamin > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Sandler-develop mailing list > San...@li... > https://lists.sourceforge.net/lists/listinfo/sandler-develop |
|
From: Benjamin R. <fir...@us...> - 2005-02-02 13:29:03
|
Hello, I'm currently developing an open source personal search engine (roosster.org) in Java. I'm planning to build the whole input/output format upon Atom, and now I'm looking for an Atom API implementation. Sandler looks very good, and I've used it in the past already. I was wondering how the state of Sandler was, expecially when considering the rather fast development of the Atom Format in the last weeks. Do you plan to adapt Sandler to these changes? When will this be? When the Format is formally a IETF standard? I just ask, because it seems as there was no Sandler development in the last 6 months, and I don't want to base my project on a probably stalled project. Thanks for your help Benjamin |
|
From: David C. <da...@bl...> - 2004-11-04 01:24:02
|
Patch applied in CVS. -David On 11/1/04 2:03 PM, "Steve Quint" <li...@na...> wrote: > At 12:02 PM -0400 10/28/04, David Czarnecki wrote: >> I checked in changes to CVS to make sure the exceptions are thrown >> and logged so >> that you will not remain in an infinite loop. > > And your changes deals with the problem just fine. There's really no > point in my submitting my original patch. The only difference is > that I had re-wrapped the IOException in a XmlPullParserException as > to not change any method signatures. > > However, the try catch block inside each of the "do/while" loops are > completely redundant. The documentation on XmlPullParserException is > not clear whether this condition is recoverable (whereas an > IOException will always be fatal). The way it is handled now, it is > always treated as a fatal error, so the only thing you get by having > a catch inside the loop is a redundant logging statement. > > I've submitted a patch to remove the "try/catch" blocks. |
|
From: David C. <da...@bl...> - 2004-11-04 01:23:32
|
I haven't kept up with the XPP used in Sandler. Mark might have a better idea. Patch applied in CVS. -David On 11/1/04 2:12 PM, "Steve Quint" <li...@na...> wrote: > The current implementation of AtomDiscovery uses the XmlPullParser as > the underlying XML parser. Being an XML parser, it doesn't handle > non-XML documents very well. So the AtomDiscovery class fails > miserably when given an URL that does not return a well formed XHTML > document. > > Are there other XML pull parsers that is more forgiving? > > I've also included a patch to allow this class to resolve relative URLs. |
|
From: Steve Q. <li...@na...> - 2004-11-01 19:11:37
|
The current implementation of AtomDiscovery uses the XmlPullParser as the underlying XML parser. Being an XML parser, it doesn't handle non-XML documents very well. So the AtomDiscovery class fails miserably when given an URL that does not return a well formed XHTML document. Are there other XML pull parsers that is more forgiving? I've also included a patch to allow this class to resolve relative URLs. -- Steve ------------------------------------------------------------ "Always ... always remember: Less is less. More is more. More is better. And twice as much is good too. Not enough is bad. And too much is never enough except when it's just about right." -- The Tick ------------------------------------------------------------ |
|
From: Steve Q. <li...@na...> - 2004-11-01 19:02:12
|
At 12:02 PM -0400 10/28/04, David Czarnecki wrote: >I checked in changes to CVS to make sure the exceptions are thrown >and logged so >that you will not remain in an infinite loop. And your changes deals with the problem just fine. There's really no point in my submitting my original patch. The only difference is that I had re-wrapped the IOException in a XmlPullParserException as to not change any method signatures. However, the try catch block inside each of the "do/while" loops are completely redundant. The documentation on XmlPullParserException is not clear whether this condition is recoverable (whereas an IOException will always be fatal). The way it is handled now, it is always treated as a fatal error, so the only thing you get by having a catch inside the loop is a redundant logging statement. I've submitted a patch to remove the "try/catch" blocks. -- Steve ------------------------------------------------------------ "Always ... always remember: Less is less. More is more. More is better. And twice as much is good too. Not enough is bad. And too much is never enough except when it's just about right." -- The Tick ------------------------------------------------------------ |
|
From: David C. <da...@bl...> - 2004-10-28 18:17:48
|
Quoting Steve Quint <li...@na...>:
> At 12:02 PM -0400 10/28/04, David Czarnecki wrote:
> >I checked in changes to CVS to make sure the exceptions are thrown
> >and logged so
> >that you will not remain in an infinite loop.
>
> I don't yet see the CVS updates in my checkout. I'll generate a
> patch against CVS tomorrow morning to avoid any conflicts.
It's probably because the anonymous CVS access lags behind developer CVS
access.
>
>
> >And if you've got the start of an Atom client, I'd be happy to test.
>
> I'm only doing the bare minimum needed to support my needs at the
> moment (for posting a new entry), and it amounts to 10 lines of code
> added to a proprietary class. I plan on doing much more with Atom
> soon for a different project, so I'll wait until then to submit a
> client.
>
> I was wondering how many more places this usage pattern appears?
> Maybe I'll do a global search for "do" tomorrow.
I did the do { ... } search. I changed the offending code in XPPBuilder and
StAXBuilder.
-David
>
> --
>
> Steve
>
> ------------------------------------------------------------
> "Always ... always remember: Less is less. More is more. More is
> better. And twice as much is good too. Not enough is bad. And too
> much is never enough except when it's just about right."
> -- The Tick
> ------------------------------------------------------------
>
|
|
From: Steve Q. <li...@na...> - 2004-10-28 18:07:39
|
At 12:02 PM -0400 10/28/04, David Czarnecki wrote: >I checked in changes to CVS to make sure the exceptions are thrown >and logged so >that you will not remain in an infinite loop. I don't yet see the CVS updates in my checkout. I'll generate a patch against CVS tomorrow morning to avoid any conflicts. >And if you've got the start of an Atom client, I'd be happy to test. I'm only doing the bare minimum needed to support my needs at the moment (for posting a new entry), and it amounts to 10 lines of code added to a proprietary class. I plan on doing much more with Atom soon for a different project, so I'll wait until then to submit a client. I was wondering how many more places this usage pattern appears? Maybe I'll do a global search for "do" tomorrow. -- Steve ------------------------------------------------------------ "Always ... always remember: Less is less. More is more. More is better. And twice as much is good too. Not enough is bad. And too much is never enough except when it's just about right." -- The Tick ------------------------------------------------------------ |
|
From: David C. <da...@bl...> - 2004-10-28 16:16:31
|
I checked in changes to CVS to make sure the exceptions are thrown and logged so
that you will not remain in an infinite loop.
And if you've got the start of an Atom client, I'd be happy to test.
-David
Quoting David Czarnecki <da...@bl...>:
> Definitely submit a patch and either myself or Mark will get it added and
> we'll
> release a new version.
>
> -David
>
> Quoting Steve Quint <li...@na...>:
>
> > While playing with Sandler as a foundation for a Atom client, I ran
> > into a problem where I would be stuck in an infinite loop. I tracked
> > this down to the LinkTagParser class.
> >
> > Later in my tests, I noticed that my Blojsom installation was also
> > stuck in an infinite loop. I tracked that problem down to the
> > XPPBuilder class.
> >
> > The root of the problem is the same usage pattern used in both classes:
> >
> > do {
> > ...
> > try {
> > ...
> > } catch ( XmlPullParserException e ) {
> > ...
> > } catch ( IOException e ) {
> > ...
> > }
> > } while ( condition );
> >
> > If an IOException occurs, you'll be stuck in the do loop, which is
> > what had happened to me in both cases.
> >
> > I would submit a patch for both files, but as someone who is new to
> > this code, I have no idea how many other places this usage pattern
> > appears. Where do we go from here?
> > --
> >
> > Steve
> >
> > ------------------------------------------------------------
> > "Always ... always remember: Less is less. More is more. More is
> > better. And twice as much is good too. Not enough is bad. And too
> > much is never enough except when it's just about right."
> > -- The Tick
> > ------------------------------------------------------------
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Sybase ASE Linux Express Edition - download now for FREE
> > LinuxWorld Reader's Choice Award Winner for best database on Linux.
> > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> > _______________________________________________
> > Sandler-develop mailing list
> > San...@li...
> > https://lists.sourceforge.net/lists/listinfo/sandler-develop
> >
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Sandler-develop mailing list
> San...@li...
> https://lists.sourceforge.net/lists/listinfo/sandler-develop
>
|
|
From: David C. <da...@bl...> - 2004-10-28 13:13:13
|
Definitely submit a patch and either myself or Mark will get it added and we'll
release a new version.
-David
Quoting Steve Quint <li...@na...>:
> While playing with Sandler as a foundation for a Atom client, I ran
> into a problem where I would be stuck in an infinite loop. I tracked
> this down to the LinkTagParser class.
>
> Later in my tests, I noticed that my Blojsom installation was also
> stuck in an infinite loop. I tracked that problem down to the
> XPPBuilder class.
>
> The root of the problem is the same usage pattern used in both classes:
>
> do {
> ...
> try {
> ...
> } catch ( XmlPullParserException e ) {
> ...
> } catch ( IOException e ) {
> ...
> }
> } while ( condition );
>
> If an IOException occurs, you'll be stuck in the do loop, which is
> what had happened to me in both cases.
>
> I would submit a patch for both files, but as someone who is new to
> this code, I have no idea how many other places this usage pattern
> appears. Where do we go from here?
> --
>
> Steve
>
> ------------------------------------------------------------
> "Always ... always remember: Less is less. More is more. More is
> better. And twice as much is good too. Not enough is bad. And too
> much is never enough except when it's just about right."
> -- The Tick
> ------------------------------------------------------------
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Sandler-develop mailing list
> San...@li...
> https://lists.sourceforge.net/lists/listinfo/sandler-develop
>
|
|
From: Steve Q. <li...@na...> - 2004-10-28 02:55:59
|
While playing with Sandler as a foundation for a Atom client, I ran
into a problem where I would be stuck in an infinite loop. I tracked
this down to the LinkTagParser class.
Later in my tests, I noticed that my Blojsom installation was also
stuck in an infinite loop. I tracked that problem down to the
XPPBuilder class.
The root of the problem is the same usage pattern used in both classes:
do {
...
try {
...
} catch ( XmlPullParserException e ) {
...
} catch ( IOException e ) {
...
}
} while ( condition );
If an IOException occurs, you'll be stuck in the do loop, which is
what had happened to me in both cases.
I would submit a patch for both files, but as someone who is new to
this code, I have no idea how many other places this usage pattern
appears. Where do we go from here?
--
Steve
------------------------------------------------------------
"Always ... always remember: Less is less. More is more. More is
better. And twice as much is good too. Not enough is bad. And too
much is never enough except when it's just about right."
-- The Tick
------------------------------------------------------------
|
|
From: Lokesh S. <ls...@vi...> - 2004-10-04 16:57:55
|
Thanks. =20 ~Lokesh =20 =20 -----Original Message----- From: Mark Lussier [mailto:mar...@ca...]=20 Sent: Monday, October 04, 2004 9:49 AM To: Lokesh Shah; san...@li... Subject: Re: [Sandler-develop] Publish to a blog =20 I do need to start spending more time on Gilmore and get a release out soon. I waiting for the API changes to complete before I dove deep into it (and the next sandler release).. Soon.. M On 10/4/04 9:41 AM, "Lokesh Shah" <ls...@vi...> wrote: Thanks David. I had a look at Gilmore APIs. They are just what I was looking for.=20 What are the plans for Gilmore? Are we expecting a release soon. =20 Regards, Lokesh =20 =20 -----Original Message----- From: san...@li... [mailto:san...@li...] <mailto:san...@li...%5d> On Behalf Of David Czarnecki Sent: Sunday, October 03, 2004 4:29 PM To: san...@li... Subject: Re: [Sandler-develop] Publish to a blog The following example shows feed discovery,=20 http://wiki.intabulas.org/confluence/display/SANDLER/Feed+Discovery Mark had started some Atom API client code, Gilmore, in CVS ( http://cvs.sourceforge.net/viewcvs.py/sandler/gilmore/), however that's not nearly complete. Maybe it could be a starting point. -David On 10/1/04 6:44 PM, "Lokesh Shah" <ls...@vi...> wrote: Yes and also how to post to my blog? =20 Regards, Lokesh =20 =20 -----Original Message----- From: san...@li... [mailto:san...@li...] <mailto:san...@li...%5d> <mailto:san...@li...%5d> <mailto:san...@li...%5d> On Behalf Of David Czarnecki Sent: Friday, October 01, 2004 3:38 PM To: san...@li... Subject: Re: [Sandler-develop] Publish to a blog Are you asking about discovery of the Atom API endpoints for your blog? -David=20 On 9/30/04 8:27 PM, "Lokesh Shah" <ls...@vi...> wrote: Does Sandler allow me to public viw atom APIs to my blog? If yes, any document which can point me in the right direction? =20 Regards, Lokesh =20 =20 |
|
From: Mark L. <mar...@ca...> - 2004-10-04 16:49:07
|
I do need to start spending more time on Gilmore and get a release out soon= . I waiting for the API changes to complete before I dove deep into it (and the next sandler release).. Soon.. M On 10/4/04 9:41 AM, "Lokesh Shah" <ls...@vi...> wrote: > Thanks David. > I had a look at Gilmore APIs. They are just what I was looking for. > What are the plans for Gilmore? Are we expecting a release soon. > =20 > Regards, > Lokesh > =20 > =20 > -----Original Message----- > From: san...@li... > [mailto:san...@li...] On Behalf Of David > Czarnecki > Sent: Sunday, October 03, 2004 4:29 PM > To: san...@li... > Subject: Re: [Sandler-develop] Publish to a blog > =20 > The following example shows feed discovery, >=20 > http://wiki.intabulas.org/confluence/display/SANDLER/Feed+Discovery >=20 > Mark had started some Atom API client code, Gilmore, in CVS ( > http://cvs.sourceforge.net/viewcvs.py/sandler/gilmore/), however that=B9s n= ot > nearly complete. Maybe it could be a starting point. >=20 > -David >=20 >=20 > On 10/1/04 6:44 PM, "Lokesh Shah" <ls...@vi...> wrote: > Yes and also how to post to my blog? > =20 > Regards, > Lokesh > =20 > =20 > -----Original Message----- > From: san...@li... > [mailto:san...@li...] > <mailto:san...@li...%5d> On Behalf Of Davi= d > Czarnecki > Sent: Friday, October 01, 2004 3:38 PM > To: san...@li... > Subject: Re: [Sandler-develop] Publish to a blog >=20 > Are you asking about discovery of the Atom API endpoints for your blog? >=20 > -David=20 >=20 >=20 > On 9/30/04 8:27 PM, "Lokesh Shah" <ls...@vi...> wrote: > Does Sandler allow me to public viw atom APIs to my blog? > If yes, any document which can point me in the right direction? > =20 > Regards, > Lokesh > =20 >=20 >=20 > =20 >=20 |
|
From: Lokesh S. <ls...@vi...> - 2004-10-04 16:42:34
|
Thanks David. I had a look at Gilmore APIs. They are just what I was looking for.=20 What are the plans for Gilmore? Are we expecting a release soon. =20 Regards, Lokesh =20 =20 -----Original Message----- From: san...@li... [mailto:san...@li...] On Behalf Of David Czarnecki Sent: Sunday, October 03, 2004 4:29 PM To: san...@li... Subject: Re: [Sandler-develop] Publish to a blog =20 The following example shows feed discovery,=20 http://wiki.intabulas.org/confluence/display/SANDLER/Feed+Discovery Mark had started some Atom API client code, Gilmore, in CVS ( http://cvs.sourceforge.net/viewcvs.py/sandler/gilmore/), however that's not nearly complete. Maybe it could be a starting point. -David On 10/1/04 6:44 PM, "Lokesh Shah" <ls...@vi...> wrote: Yes and also how to post to my blog? =20 Regards, Lokesh =20 =20 -----Original Message----- From: san...@li... [mailto:san...@li...] <mailto:san...@li...%5d> On Behalf Of David Czarnecki Sent: Friday, October 01, 2004 3:38 PM To: san...@li... Subject: Re: [Sandler-develop] Publish to a blog Are you asking about discovery of the Atom API endpoints for your blog? -David=20 On 9/30/04 8:27 PM, "Lokesh Shah" <ls...@vi...> wrote: Does Sandler allow me to public viw atom APIs to my blog? If yes, any document which can point me in the right direction? =20 Regards, Lokesh =20 =20 |
|
From: David C. <da...@bl...> - 2004-10-03 23:24:49
|
The following example shows feed discovery, http://wiki.intabulas.org/confluence/display/SANDLER/Feed+Discovery Mark had started some Atom API client code, Gilmore, in CVS ( http://cvs.sourceforge.net/viewcvs.py/sandler/gilmore/), however that=B9s not nearly complete. Maybe it could be a starting point. -David On 10/1/04 6:44 PM, "Lokesh Shah" <ls...@vi...> wrote: > Yes and also how to post to my blog? > =20 > Regards, > Lokesh > =20 > =20 > -----Original Message----- > From: san...@li... > [mailto:san...@li...] On Behalf Of David > Czarnecki > Sent: Friday, October 01, 2004 3:38 PM > To: san...@li... > Subject: Re: [Sandler-develop] Publish to a blog > =20 > Are you asking about discovery of the Atom API endpoints for your blog? >=20 > -David=20 >=20 >=20 > On 9/30/04 8:27 PM, "Lokesh Shah" <ls...@vi...> wrote: > Does Sandler allow me to public viw atom APIs to my blog? > If yes, any document which can point me in the right direction? > =20 > Regards, > Lokesh > =20 > =20 >=20 |
|
From: David C. <da...@bl...> - 2004-10-01 22:35:32
|
Are you asking about discovery of the Atom API endpoints for your blog? -David On 9/30/04 8:27 PM, "Lokesh Shah" <ls...@vi...> wrote: > Does Sandler allow me to public viw atom APIs to my blog? > If yes, any document which can point me in the right direction? > > Regards, > Lokesh > > |
|
From: Lokesh S. <ls...@vi...> - 2004-10-01 00:27:57
|
Does Sandler allow me to public viw atom APIs to my blog? If yes, any document which can point me in the right direction? =20 Regards, Lokesh =20 |
|
From: David C. <da...@bl...> - 2004-06-01 19:04:41
|
Yay for us :) http://wiki.intabulas.org/confluence/display/SANDLER/About%2BSandler -David |
|
From: David C. <cza...@ac...> - 2004-05-27 00:36:35
|
I think the Commons HTTPClient API would suffice. It does have a stable 2.0 release and HTTPClient 3.0 should be available soon. But as an API, it's fairly robust. If it works, let's use it. -David On 5/26/04 5:40 PM, "Mark Lussier" <ma...@ca...> wrote: > So I decided to move the client api fragments I had started out into > it's own sister jar, currently named Gilmore. The intent is to create a > complete toolkit for doing client side Atom API implementations. > > So on that note, to avoid the commons-* nightmare, if anyone has a link > to a useful (and opensource) HTTP toolkit (other than > commons-httpclient) I would love the link > > M > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Sandler-develop mailing list > San...@li... > https://lists.sourceforge.net/lists/listinfo/sandler-develop |
|
From: Mark L. <ma...@ca...> - 2004-05-26 21:40:31
|
So I decided to move the client api fragments I had started out into it's own sister jar, currently named Gilmore. The intent is to create a complete toolkit for doing client side Atom API implementations. So on that note, to avoid the commons-* nightmare, if anyone has a link to a useful (and opensource) HTTP toolkit (other than commons-httpclient) I would love the link M |
|
From: Mark L. <ma...@ca...> - 2004-05-26 21:36:18
|
Release codename: Little Nicky I have released 0.7 out into the wild, most likely the last release before 1.0. I want to thank Brian and Dave for helping making this releases even better Changelog ========= * Upgraded Atom authentication routines to support the new specification * New SAX serializer (thanks to Brian McCallister) * New StAX serializer and parser (Still a bit flakey) * All parsing code refactored into a simplistic builder model * Fixed a bug with marshalling Entry's * Link elements now manage the rel="Alternate" rules * Added createGenerator() convenience methods to the SyndicationFactory * Added createContent() convenience methods for generic text/plain content to the SyndicationFactory * Content type elements no longer carry their output tag names, moved that to the serializers * Moved to a newer version of the XPP3 Jar (1.1.3.4d_b4) * Moved all of the serialization code out of the elements * Added a new Serializer that works with Writer's * Fixed a problem with the serializer for the Generator element. It was not emmiting the proper values for uri and version attributes * New method getEntries() added to the Feed element to return a List of all the entries (frums) * New method getContributors() added to the Entry element to return a List of all contributors (frums) |
|
From: <ben...@id...> - 2004-05-25 08:35:35
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Mark L. <mar...@ca...> - 2004-05-09 17:30:35
|
Actually I did that a few days ago (not checked in yet).. Origionally = the string code was a breakout of the self parsing and serializing = elements, then the additional serializers came.. I will check that in = today... =20 M -----Original Message----- From: san...@li... on behalf of David = Czarnecki Sent: Sun 5/9/2004 8:58 AM To: san...@li... Subject: [Sandler-develop] StringSerializer needed? =20 I was wondering what benefit StringSerializer provides when one can just pass the WriterSerializer an instance of a StringWriter that basically accomplishes the same thing as would the StringSerializer. If we don't want to remove StringSerializer, I'd like to just have it = create a StringWriter internally and use the WriterSerializer that way we're = not duplicating code. If we want to remove StringSerializer, well, then = we'll just remove it.=20 Thoughts? -David ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to=20 deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3 _______________________________________________ Sandler-develop mailing list San...@li... https://lists.sourceforge.net/lists/listinfo/sandler-develop |
|
From: David C. <cza...@ac...> - 2004-05-09 15:57:03
|
I was wondering what benefit StringSerializer provides when one can just pass the WriterSerializer an instance of a StringWriter that basically accomplishes the same thing as would the StringSerializer. If we don't want to remove StringSerializer, I'd like to just have it create a StringWriter internally and use the WriterSerializer that way we're not duplicating code. If we want to remove StringSerializer, well, then we'll just remove it. Thoughts? -David |
|
From: Mark L. <ma...@ca...> - 2004-04-14 20:36:50
|
Sorry it took a bit to reply, I lost my DSL while working at home yesterday. So I have read this a few times and re-read that section of the spec (http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html#rfc.section.4.13.10 for those lurking) and at this point I think specifing a default selector is not all that bad. I think you jstl example is quite a good argument for it, though the long method name aint my favorite choice.. We could also make a assumption that setting a general ContentSelector for the builder would be enough and the model where it needs it uses it. M > Looking at the Atom Syndication Spec (tm) I notice that although an > Entry can have multiple Content elements, the client is only ever > supposed to display one. > > I would like to provide a means for obtaining this one via an > <code>Entry.getContent(): Content</code> method but cannot decide best > way to do it. > > Options I am considering: > > on the Builders provide the ability to specify a ContentSelector which > will be an interface which, when passed an array/collection of Entry > instances will return a single Entry which will be the default: > > <code>XPPBuilder.setDefaultEntryContentSelector(ContentSelector): > null</code> but this doesn't feel completely correct. The main reason I > want to be able to specify this somewhere, rather than present it as a > <code>Entry.selectContent(ContentSelector): Entry</code> is that I > would like to make Sandler elements JEXL/OGNL friendly, and passing > args (especially complicated ones) is a bear there. > > <channel> > ... > <c:forEach items="${feed.entries}" var="entry"> > <item> > ... > ${entry.content.body} > </item> > </c:forEach> > > is nice to be able to do =) > > Any thoughts? > > -Brian > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Sandler-develop mailing list > San...@li... > https://lists.sourceforge.net/lists/listinfo/sandler-develop |
