Re: [morph-developer] Damn Verizon

[Matt B. <gud...@ya...>]

Pow!  I couldn't even be troubled to do an inline
post.  The "projection" thing you mention is inherent
to JXPATH--hadn't noticed it when I've played with
OGNL.  One thing about OGNL is its almost utter lack
of support.  I know JXPATH is supported because I'm
its "curator."  ;)  And I'm pretty sure JXPATH could
support Morph reflectors _now_.  I'll try it sometime.

-MB

--- Matt Sgarlata
<Mat...@wh...> wrote:

> Matt Benson wrote:
> > --- Matt Sgarlata
> > <Mat...@wh...> wrote:
> >
> >   
> >> Comments inline....
> >>     
> >>> :)  I think making expressions perfectly safe
> for
> >>>       
> >> this
> >>     
> >>> copier will require more knowledge of how the
> >>> expression is parsed, along the lines of my
> >>> earlier-voiced thoughts about expressions in
> >>>       
> >> Morph. 
> >>     
> >>> Maybe I'll try to cook up a BC implementation of
> >>>       
> >> this.
> >>     
> >>>   
> >>>       
> >> One of my original frustrations with BeanUtils is
> >> when it encountered 
> >> something unexpected it would blowup at you and
> ruin
> >> your day.  With 
> >> Morph I strove to just silently fail where
> possible
> >> and only throw 
> >> exceptions when something really boneheaded
> happened
> >> (like trying to 
> >> convert "hello world!" to an Integer).
> >>
> >> I'm pretty sure what will happen if you enter a
> >> totally bogus expression 
> >> is you'll get a blowup.  If you enter an
> expression
> >> for an object path 
> >> and a null is encountered part way through, I'm
> >> pretty sure a null will 
> >> just be returned.
> >>
> >> Don't be intimidated by the expression parsing
> >> stuff, it's really very 
> >> trivial (in fact SimpleExpressionParser has less
> >> than a dozen lines of 
> >> code).  Basically the expression parser is just a
> >> StringTokenizer that 
> >> looks for symbols usually found in languages like
> .
> >> [ ] ( ) and then 
> >> just treats them all as word breaks.  So
> >> something.funky]like[this in 
> >> Morph is equivalent to something.funky.like.this
> in
> >> a more strict 
> >> language like JSTL.  Why be so strict with your
> >> syntax when the whole 
> >> point of this new syntax (as opposed to strongly
> >> typed Java calls) is to 
> >> ignore types and make things easier on yourself?
> ;)
> >>
> >>     
> >
> > I'm not sure... I understand what you're saying,
> but
> > somehow I can't rid myself of this feeling that
> _some_
> > structure might be a good thing.  I'll let you
> know if
> > I come up with anything concrete.  In the meantime
> I
> > still can't see the harm in refactoring some
> things
> > while retaining the SL functionality... :)
> >   
> This was actually a design choice.  Why make a
> distinction between a 
> collection and a bean?  The only real difference
> between the two is that 
> a collection happens to have property names that are
> numbers instead of 
> words.  IMO the distinction made in other languages
> is an implementation 
> crutch rather than a useful feature.  If someone
> wants to write 
>
my[[[[[[[[[[really[[[[[[[[[[[[[[[[[[obnoxious.[][][][][path
> then they 
> are being obnoxious on purpose.  I expect most
> people are going to go 
> for a.not.obnoxious.path.  And you also have the
> option of being strict 
> if you want with object.listProperty[myIndex].  The
> nice thing about 
> SimpleLanguage is it implements JSTL EL, Velocity
> and many other untyped 
> languages so that you can take existing expressions
> and just plug it 
> into Morph and it will work.  You can also write new
> expressions with 
> whatever syntax are comfortable with.
> 
> The one big thing this functionality is missing is
> the stuff you can do 
> with OGNL like projections.  I haven't looked into
> that library too 
> much, but here's one feature I find really
> appealing.  Say we have a 
> list of People called employeeDirectory.  Then you
> can do 
> "employeeDirectory.address.street" and get a List of
> street address.  I 
> believe this is called projection and is a feature
> in OGNL.  Again here 
> it doesn't seem like you would need to have any
> syntax difference 
> between a projection and a regular query on an
> object graph.  Just use 
> reflectors to figure out, oh, employeeDirectory is a
> collection and its 
> members all have an address property, so I'll go get
> the addresses for 
> each of these people.  Perhaps in this case where
> you are doing a 
> different type of operation than normal I could
> justify a syntax 
> difference.  Retrieving a property from an object
> vs. retrieving an 
> object at specific index in a collection is not a
> significant enough 
> difference to justify different syntax, IMO.
> 
> If we could get OGNL to base some of their stuff off
> Morph I would be 
> very happy to deprecate the Language code in Morph. 
> OGNL is much more 
> capable, but some of its interfaces are kind of
> ugly.  I know its 
> Transformer interface has a half dozen parameters.
> 
> Matt S
> >
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get
> the chance to share your
> opinions on IT & business topics through brief
> surveys-and earn cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
_______________________________________________
> morph-developer mailing list
> mor...@li...
>
https://lists.sourceforge.net/lists/listinfo/morph-developer
> 



 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php