Hi Alex,
thanks for the changes all have more sense that way now.
One question about Jewel ListItemRenderer.as
in line 56
addClass("selectable");
that should remain?
I guess it must be removed (like in "NavigationLinkItemRenderer" and "
TabBarButtonItemRenderer"
right?El jue., 20 feb. 2020 a las 23:03, Alex Harui (<aha...@adobe.com.invalid>) escribió: > I pushed changes that I think has everything working in Jewel by using the > same "has" pattern that is used in other component sets. > > The Lists in the ToDo examples use a regular ItemRendererClassFactory > instead of SelectableItemRendererClassFactory that is now used in most > other places (List/DataGrid/Table) > > The recommended pattern for disabling selection in a list is whether you > choose a ClassFactory that attaches a Selection Bead to each renderer. > There was an exception to that rule in one of the Table examples because it > wanted only certain renderers to not have selection. I added a bead that > turns off the selection for that case. IMO, how to deal with such an > exception will be based more on what percentage of the renderers need > selection. If most do, then add a Selection Bead to all renderers but > disable selection where you don't want it. If most do not want selection, > then add the bead where you need it. > > Thanks, > -Alex > > On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote: > > yes, Jewel has the "structure" and is organized in SASS files, then > JewelTheme has the "styling" part and is as well SASS. > so Jewel should not need to change, and people should only need to > change > JewelTheme or create a new theme one using it as a template. > > I'll add examples to ant tomorrow > > thanks > > > El jue., 20 feb. 2020 a las 20:17, Alex Harui > (<aha...@adobe.com.invalid>) > escribió: > > > > > > > On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrov...@apache.org> > wrote: > > > > forgot to say. Can you add missing examples to ANT? don't know > where > > to do > > that > > and checking Jewel don't see the use of > > SelectableItemRendererClassFactory. > > all times ItemRendererClassFactory is used > > > > I could fix the Ant side, but I don't have time. It think all you > need to > > do is add it to the examples/build.xml > > > > I didn't use SelectableItemRendererClassFactory in Jewel because I > wasn't > > sure if the selection was supposed to be changeable at runtime. I > think > > you've confirmed that it isn't so we can change to use > > SelectableItemRendererClassFactory > > > > I knew the themes were generated by SASS, but I didn't realize the > Jewel > > one was as well. > > > > -Alex > > > > El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (< > > carlosrov...@apache.org>) > > escribió: > > > > > Hi Alex, > > > > > > remember that Jewel uses SASS to create the CSS. I already > pushed a > > commit > > > with ["warning"]. It's not the first time I warn about it ;) > > > You must to change SASS file. The css is just generated (like > other > > > generations in compiler), and is committed since no body added > SASS > > to ANT. > > > Maven has a sass plugin to compile SASS. > > > > > > I saw you response and commented there > > > > > > Thanks > > > > > > Carlos > > > > > > > > > El jue., 20 feb. 2020 a las 19:55, Alex Harui > > (<aha...@adobe.com.invalid>) > > > escribió: > > > > > >> I replied on this topic on your commit email. > > >> > > >> So I don't have to copy that into this thread, read what I > said in > > that > > >> email and reply on that thread and let's figure out the right > thing > > to do. > > >> I am having some weird problem with my Maven build where > every time > > I try > > >> to change Jewel's defaults.css something overwrites it. I'm > trying > > to > > >> figure out what is going on there. > > >> > > >> -Alex > > >> > > >> On 2/20/20, 10:47 AM, "Carlos Rovira" < > carlosrov...@apache.org> > > wrote: > > >> > > >> Hi Alex, > > >> > > >> I found that TodoMVC examples was not working, so I fixed > it > > removing > > >> the > > >> non existing properties (hoverable and selectable). > > >> But I found Jewel ListItemRenderer has all baked, so I > created a > > >> SimpleListItemRenderer (in Jewel Simple in the normal > prefix > > for a > > >> "base", > > >> "basic" or "simple" option) that hast the minimum > required. > > >> > > >> So at least in Jewel if people wants hoverable and > selectable > > >> renderers use > > >> the normal ListItemRenderer. > > >> If don't want that indicators, use > SimpleListItemRenderer. If > > you > > >> want just > > >> show hover, but not selected state, then extend Simple > version > > and > > >> add " > > >> ClassSelectorListRuntimeSelectableItemRendererBead" and > > configure to > > >> have > > >> just "hoverable" to true ¿ok? > > >> > > >> Hope I understand ok how it works. Let me know if > something is > > not as > > >> expected. > > >> > > >> Thanks > > >> > > >> Carlos > > >> > > >> > > >> > > >> El jue., 20 feb. 2020 a las 18:06, Alex Harui > > >> (<aha...@adobe.com.invalid>) > > >> escribió: > > >> > > >> > I'm not sure I understand what you mean by "control". > > >> > > > >> > Before the "has" changes, every ItemRenderer contained > or > > inherited > > >> code > > >> > that had hovered/selected APIs that drew visuals, and > the > > >> ItemRenderer also > > >> > "had" a bead like ItemRendererMouseController that set > the > > hovered > > >> property > > >> > on that item renderer, and the List's controller would > set the > > >> selected > > >> > property. > > >> > > > >> > Now, every ItemRenderer "has" a bead that has the > > hovered/selected > > >> > properties, and the ItemRendererMouseController and the > > Lists's > > >> controllers > > >> > get that bead instead of talking to the ItemRenderer > > directly. I > > >> guess > > >> > that's the new way of thinking for has/composition vs > > >> is/inheritance: a > > >> > component doesn't have to have all of its APIs glued to > its > > API > > >> surface. > > >> > We mainly do that for convenience in MXML, but for more > > internal > > >> stuff like > > >> > this, loose-coupling via has/composition shared more > code and > > >> increases > > >> > configurability, but does add some runtime overhead in > its > > raw form. > > >> > Hopefully we can optimize that away. > > >> > > > >> > HTH, > > >> > -Alex > > >> > > > >> > On 2/20/20, 5:01 AM, "Piotr Zarzycki" < > > piotrzarzyck...@gmail.com> > > >> wrote: > > >> > > > >> > Hi Alex, > > >> > > > >> > Could you provide an example how would I control > > >> hovering/selecting in > > >> > item > > >> > renderer when I don't have build in hover property > etc. ? > > How > > >> should I > > >> > compose such item renderer ? > > >> > > > >> > Thanks, > > >> > Piotr > > >> > > > >> > czw., 20 lut 2020 o 03:20 Alex Harui > > <aha...@adobe.com.invalid> > > >> > napisał(a): > > >> > > > >> > > I pushed the "has" changes. TourDeJewel seems to > be > > working > > >> > correctly for > > >> > > me. > > >> > > > > >> > > The principle of "has" is similar to inheritance > vs > > >> composition. > > >> > Just > > >> > > like top-level components like List are composed > of many > > >> beads, the > > >> > item > > >> > > renderers are now composed of more beads as > well. That > > >> reduces the > > >> > > requirement to add code to a class in order to > "be/is" > > >> something. > > >> > > > > >> > > There used to be copies of code that drew hover > and > > selected > > >> states > > >> > on > > >> > > the item renderers in each new kind of item > renderer > > that > > >> couldn't > > >> > inherit > > >> > > from an item renderer that could draw selected and > > hovered > > >> states. > > >> > Now, > > >> > > the itemrenderers compose their selection > visuals. A > > single > > >> item > > >> > renderer > > >> > > like StringItemRenderer can be composed with no > > selection > > >> drawing at > > >> > all, > > >> > > or with solid color selection drawing or with > alternate > > color > > >> > selection > > >> > > drawing or something new. And that means that > some > > new > > >> kind of > > >> > item > > >> > > renderer, like a TextInput can become an item > renderer > > more > > >> easily, > > >> > by > > >> > > composing a selection visuals bead instead of > having to > > add > > >> all of > > >> > that > > >> > > code. > > >> > > > > >> > > Another place I started using "has" but didn't > fully > > replace > > >> the old > > >> > code > > >> > > was in handling itemRendererParent, which is now > called > > >> > > itemRendererOwnerView (to try to make it more > clear > > that isn't > > >> > always the > > >> > > parent of the item renderer and is sometimes an > internal > > >> > > datagroup/container). Turns out a lot of our > renderers > > >> didn't need > > >> > to know > > >> > > the itemRendererParent, so in many cases we no > longer > > figure > > >> it out > > >> > and > > >> > > assign it. But in cases where it is needed, the > > property is > > >> > currently left > > >> > > baked into the renderer, but in some new cases, > it is > > >> composed. An > > >> > > ItemRendererOwnerViewBead is added to the strand > > instead of > > >> added to > > >> > a > > >> > > class and contains the reference to the ownerView. > > Maybe > > >> someday > > >> > we'll > > >> > > fully remove the old pattern, not sure. > > >> > > > > >> > > Ideally we would do more "has" than "is". It > could > > allow us > > >> to > > >> > eliminate > > >> > > much of the required code to be a top tag in an > MXML > > document. > > >> > > > > >> > > Other changes in this branch were to add > "Initializers" > > so the > > >> > > RendererFactories didn't bake in code for > specific item > > >> renderers, > > >> > and to > > >> > > create a few base classes with overrides so there > is > > less > > >> code to > > >> > maintain. > > >> > > > > >> > > There should be little if any impact to > application > > code. It > > >> should > > >> > > mainly affect the internals of how item > renderer-based > > things > > >> are > > >> > created. > > >> > > > > >> > > Thanks, > > >> > > -Alex > > >> > > > > >> > > On 2/17/20, 4:33 PM, "Carlos Rovira" < > > carlosrov...@apache.org > > >> > > > >> > wrote: > > >> > > > > >> > > Hi Alex, > > >> > > > > >> > > if will be of help if you point us to > different > > links > > >> where we > > >> > can > > >> > > learn > > >> > > about this modifications, since I at least > can just > > >> imagine what > > >> > is all > > >> > > about, but will need to get deeper in the > concepts > > to > > >> understand > > >> > the > > >> > > changes and to apply this patterns. > > >> > > > > >> > > In Jewel each "list component has its own > type of > > >> renderer, so > > >> > for > > >> > > example > > >> > > List uses ListItemRenderer and DataGrid has > > >> > DataGridItemRenderer, since > > >> > > usually at that component level the user needs > > similar > > >> > infrastructure > > >> > > like > > >> > > hoverable, selectable...and some (not much) > more, > > don't > > >> know > > >> > right now > > >> > > how > > >> > > all this will fit with the "has" new > > pattern....I'll try > > >> it. > > >> > > > > >> > > Just one important thing. There's actual > users and > > >> clients using > > >> > Jewel > > >> > > and > > >> > > other UI sets and are with very short times > for > > their > > >> > migrations, so > > >> > > just > > >> > > want to ask you to test as much as possible, > since > > TDJ > > >> has many > > >> > > examples > > >> > > now. Other thing you can test is new TodoMVC > to see > > how it > > >> > behaves, > > >> > > since > > >> > > it uses a List with IRs. So we can ensure (as > much > > as we > > >> can) > > >> > the merge > > >> > > left things working (as much as we can) > > >> > > > > >> > > Thanks for working on this, will try all of > this > > tomorrow > > >> > > > > >> > > Carlos > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > El lun., 17 feb. 2020 a las 22:35, Alex Harui > > >> > > (<aha...@adobe.com.invalid>) > > >> > > escribió: > > >> > > > > >> > > > I've pushed the "has" branch that contains a > > >> refactoring of > > >> > the item > > >> > > > renderers. Tour De Jewel and MDL Example > seem to > > be > > >> working > > >> > as is > > >> > > Basic > > >> > > > List Example and MX AdvancedDataGrid. > > >> > > > > > >> > > > "has" is really just calls to > getBeadByType. If > > we > > >> start to > > >> > see > > >> > > > performance issues, then we'll look into > > optimizing. > > >> The > > >> > motivation > > >> > > to > > >> > > > switch to "has" came from several bugs about > > using MX > > >> > Label/CheckBox > > >> > > as > > >> > > > item renderers. In Royale, the > ItemRenderers > > were in > > >> control > > >> > of the > > >> > > > visuals of their rollover and selected > state. > > That is > > >> a more > > >> > proper > > >> > > > encapsulation than the way it was in Flex > where > > the > > >> lists drew > > >> > the > > >> > > rollover > > >> > > > and selected states and it was hard to > override > > the > > >> visuals > > >> > for a > > >> > > custom > > >> > > > item renderer. But in the develop branch > Royale > > code, > > >> it would > > >> > > require > > >> > > > that custom itemrenderers implement a lot > of APIs > > >> related to > > >> > > rollover and > > >> > > > selected visuals. Instead we can now > reuse/share > > code > > >> for > > >> > visuals > > >> > > between > > >> > > > different renderers because a renderer now > can > > "has" a > > >> > > rollover/selection > > >> > > > implementation instead of being one. > > >> > > > > > >> > > > There are more pieces involved, but there > is more > > >> sharing of > > >> > code. > > >> > > Along > > >> > > > the way I found that there were some > not-so-PAYG > > >> patterns > > >> > being used > > >> > > in MDL > > >> > > > and Jewel renderers that might deserve > further > > >> modification. > > >> > There > > >> > > are > > >> > > > "hoverable" and "selectable" APIs that > appear to > > be > > >> used to > > >> > > permanently > > >> > > > turn off selection and hover visuals. In > > general, I > > >> think > > >> > there is > > >> > > better > > >> > > > use of PAYG and composition when > functionality is > > >> "built up" > > >> > and not > > >> > > > "turned off", so with the "has" pattern the > > renderers > > >> can be > > >> > added > > >> > > to a > > >> > > > list without any selection visuals at all > (for a > > >> non-selectable > > >> > > list) or > > >> > > > re-composed with custom visuals that only > support > > >> hoverable, > > >> > for > > >> > > example. > > >> > > > I left it "hoverable/selectable" in the API > > surface for > > >> now, > > >> > but > > >> > > something > > >> > > > to think about going forward. > > >> > > > > > >> > > > I’m going to run a few more tests before > merging > > and > > >> pushing to > > >> > > develop. > > >> > > > > > >> > > > -Alex > > >> > > > > > >> > > > On 1/15/20, 10:44 PM, "Alex Harui" > > >> <aha...@adobe.com.INVALID> > > >> > wrote: > > >> > > > > > >> > > > You are welcome to try and see how many > cache > > hits > > >> it > > >> > gets. I > > >> > > think > > >> > > > in renderers, we ask once per renderer. > I'm not > > sure > > >> there is > > >> > a > > >> > > faster way > > >> > > > to do the first lookup of "is", but for > "has" we > > could > > >> change > > >> > the > > >> > > lookup > > >> > > > and save time. > > >> > > > > > >> > > > On 1/15/20, 10:38 PM, "Greg Dove" < > > >> greg.d...@gmail.com> > > >> > wrote: > > >> > > > > > >> > > > For the 'something is > ISomeInterface' > > >> > > > I had wondered in the past if these > types > > of > > >> lookups > > >> > could be > > >> > > > incrementally > > >> > > > cached on the 'is' target (after > first > > lookup), > > >> that > > >> > might > > >> > > make > > >> > > > sense for > > >> > > > interfaces, which are the deepest > checks I > > >> think? > > >> > > > caching result (could optionally > create > > the Map) > > >> > > > > > >> ISomeInterface['implMap'].set(something.constructor, > > >> > > isResult ) > > >> > > > > > >> > > > then earlier in the interface > checks, it > > could > > >> do > > >> > something > > >> > > like: > > >> > > > if (ISomeInterface['implMap'] && > > >> > > > > > >> ISomeInterface['implMap'].has(something.constructor) ) > > >> > return > > >> > > > > > >> ISomeInterface['implMap'].get(something.constructor) > > >> > > > > > >> > > > I realize its extra code, but it > should be > > >> quite a bit > > >> > > faster over > > >> > > > time I > > >> > > > think. > > >> > > > > > >> > > > On Thu, Jan 16, 2020 at 7:20 PM > Alex Harui > > >> > > > <aha...@adobe.com.invalid> wrote: > > >> > > > > > >> > > > > Hi, > > >> > > > > > > >> > > > > Several different threads have > brought > > up > > >> issues with > > >> > > sharing > > >> > > > code between > > >> > > > > component sets. Other threads > have > > offered > > >> > different and > > >> > > clever > > >> > > > ways to > > >> > > > > do various things like how MXML is > > applied to > > >> a > > >> > component. > > >> > > > Meanwhile, over > > >> > > > > in MX emulation, I was starting > to copy > > some > > >> code > > >> > from > > >> > > Basic to > > >> > > > MXRoyale to > > >> > > > > get the various MX components to > be > > valid item > > >> > renderers. > > >> > > > MXRoyale is > > >> > > > > using Basic's item renderer > architecture > > >> which is > > >> > better > > >> > > > encapsulated: the > > >> > > > > renderer draws its hovered and > selected > > >> state. In > > >> > Flex, > > >> > > the > > >> > > > List draws > > >> > > > > over the renderer, which makes it > hard > > to > > >> customize > > >> > the > > >> > > way the > > >> > > > renderer > > >> > > > > will look when hovered and > selected. > > >> > > > > > > >> > > > > It finally occurred to me that > one of > > the > > >> reasons we > > >> > end up > > >> > > > copying code > > >> > > > > is because we are still using too > many > > "is" > > >> checks > > >> > instead > > >> > > of > > >> > > > "has" > > >> > > > > checks. I'm not even sure we > have any > > "has" > > >> checks > > >> > in the > > >> > > Royale > > >> > > > > framework. I was afraid of the > > overhead of a > > >> "has" > > >> > check, > > >> > > but > > >> > > > I'm starting > > >> > > > > to change my mind because: > > >> > > > > > > >> > > > > 1) The "is" check actually runs a > fair > > amount > > >> of > > >> > code, > > >> > > > especially for > > >> > > > > (comp is ISomeInterface) > > >> > > > > 2) The length of bead arrays > don't seem > > too > > >> long. > > >> > > > > > > >> > > > > A "has" check calls > > >> getBeadByType(ISomeInterface), > > >> > so it > > >> > > > actually will run > > >> > > > > the (bead is ISomeInterface) on > > potentially > > >> the > > >> > entire > > >> > > strand > > >> > > > array/vector, > > >> > > > > although we could speed that up by > > annotating > > >> beads > > >> > or > > >> > > keeping > > >> > > > track of > > >> > > > > what is on the strand. But the > code > > >> sharing/reuse > > >> > > potential of > > >> > > > this > > >> > > > > pattern seems significant to me. > > >> > > > > > > >> > > > > For example, it could change how > hard > > it is > > >> to make a > > >> > > component > > >> > > > usable as > > >> > > > > a top tag in MXML. Instead of the > > component > > >> having > > >> > to > > >> > > implement > > >> > > > certain > > >> > > > > methods, the component could have > a bead > > >> installed > > >> > and the > > >> > > > > MXMLDataInterpreter could talk to > that > > bead > > >> instead > > >> > of the > > >> > > > component. > > >> > > > > > > >> > > > > In the case of the item renderers, > > instead of > > >> > testing if > > >> > > the > > >> > > > renderer "is" > > >> > > > > ISelectableLIstItemRenderer, it > could > > ask if > > >> the > > >> > created > > >> > > widget > > >> > > > "has" an > > >> > > > > ISelectableLIstItemRenderer bead > and the > > >> logic in > > >> > that > > >> > > bead can > > >> > > > be reused > > >> > > > > in both Basic and MXRoyale > without being > > >> copied. > > >> > > > > > > >> > > > > Some code, like Container > overrides of > > >> addElement > > >> > probably > > >> > > can't > > >> > > > be > > >> > > > > refactored into a "has". But I > wonder > > how > > >> many other > > >> > > things > > >> > > > could. I'm > > >> > > > > not sure I would move everything > that > > could > > >> be moved > > >> > into a > > >> > > > shared bead. > > >> > > > > We'd have to think about the > overhead > > on small > > >> > components > > >> > > and > > >> > > > apps. But > > >> > > > > for MXML support and Item Renderer > > support, > > >> it seems > > >> > to > > >> > > make > > >> > > > sense. > > >> > > > > > > >> > > > > Anyway, I will look into > refactoring > > the item > > >> > renderer > > >> > > code in > > >> > > > a few days > > >> > > > > unless feedback indicates > otherwise. > > Bugs > > >> like #676 > > >> > and > > >> > > #681 > > >> > > > inspired this > > >> > > > > post. > > >> > > > > > > >> > > > > Of course, I could be wrong... > > >> > > > > -Alex > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > -- > > >> > > Carlos Rovira > > >> > > > > >> > > > > >> > > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0 > > >> > > > > >> > > > > >> > > > > >> > > > >> > -- > > >> > > > >> > Piotr Zarzycki > > >> > > > >> > Patreon: * > > >> > > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0 > > >> > < > > >> > > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0 > > >> > >* > > >> > > > >> > > > >> > > > >> > > >> -- > > >> Carlos Rovira > > >> > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0 > > >> > > >> > > >> > > > > > > -- > > > Carlos Rovira > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0 > > > > > > > > > > -- > > Carlos Rovira > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0 > > > > > > > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288402599&sdata=JcJWURIyUxG4bru0YjyB6xM%2FKPUEbNGfZ3zj%2FUB5jUU%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
