You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tapestry.apache.org by "dragan.sahpaskix@gmail.com" <dr...@gmail.com> on 2011/06/15 13:27:48 UTC

Re: GSOC Right Click Menu

Hi,

I have updated the contextmenu with other client events like mousedown,
mouseover etc. that you can look at on the new examples page
http://dragansah.com/contextmenu/parametersexamples.

You can browse the issues (mainly tasks and bugs) here
http://code.google.com/a/apache-extras.org/p/right-click-menu-gsoc2011/issues/list
and
if someone has some ideas or wishes, they can add them to the issues list.

Next on my work-log is to provide a dropdown menu as a separate component
that can be used with the existing contextmenu. It is not directly related
to the contextmenu because you can put anything in the contextmenu, but
maybe 90% of the use-cases of a contextmenu is to have a dropdown wiht icon
and a label like they have on the rich faces demo
site<http://liferay.exadel.com/web/guest> under
RichMenu->ContextMenu.

Any kind of comments or remarks are very much welcomed.

Cheers,
Dragan Sahpaski



On Tue, May 31, 2011 at 7:16 PM, Kalle Korhonen
<ka...@gmail.com>wrote:

> I'm officially Dragan's mentor but the rest of committers should
> really take a look at Dragan's excellent work if you can just spare a
> few cycles for it. The demo site (http://dragansah.com/contextmenu/)
> Dragan put together makes it easy to track the project status even if
> you don't have time to dive into the code. We already talked about the
> items via Skype but a few quick comments below..
>
> On Sun, May 29, 2011 at 1:51 PM, dragan.sahpaskix@gmail.com
> <dr...@gmail.com> wrote:
> >   1. Two mixins: ContextMenu and ContextMenuAjax or merge them in one
> >   mixin?
>
> It doesn't cost any more to use separate mixins for the user so
> probably makes sense to keep as is for now.
>
> >   2. Is the concept of advising GridCell (actualy
> AbstractPropertyOutput<
> http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/corelib/base/AbstractPropertyOutput.html#renderPropertyValue(org.apache.tapestry5.MarkupWriter
> ,
> >   java.lang.String)>) ok? Its clear that we cannot implement support of
> the
> >   t5 grid without an advice or I'm I wrong?
>
> That's the way and it didn't seem too bad at all, but if it'd be
> possible to implement it better by making a small, generic and
> backwards compatible enhancement to GridCell, I think that'd be
> preferable in the long run, just because there's some performance
> penalty whenever using an advice, and an AbstractPropertyOutput gets
> used a lot.
>
> >   5. The contextmenu is rendered after the component and there is a bit
> of
> >   The quirk is that the contextmenu forces the render of the conainer's
> >   clientId (if it is a t5 ClientElement), and uses it to set a javascript
> >   event oncontextmenu on it using the id. If the component is not a t5
> >   ClientElement (t5 Label for example), than this javascript is applied
> for
> >   getting the client element in js: $('contextMenuId').previousSibling.
> This
> >   code assumes that the parent component is only one html element (div or
> >   similar), but this is not the case for example the t5 TextField which
> >   renders a trailing icon. Luckily the TextField is covered because it is
> a
>
> Seems to me it's quite fine to require ClientElement in that case.
>
> Kalle
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>

Re: GSOC Right Click Menu

Posted by Taha Hafeez <ta...@gmail.com>.

IMHO, it will be useful to put a note/warning in the contributor's section
regarding copyright and licensing issues followed by a small
introduction(that you already gave) and then pointers to other related
resources.

regards
Taha



On Thu, Jul 7, 2011 at 11:59 AM, Kalle Korhonen
<ka...@gmail.com>wrote:

> On Wed, Jul 6, 2011 at 11:14 PM, Taha Hafeez <ta...@gmail.com>
> wrote:
> > Thanks for sharing this information. It would be great if you find time
> to
> > place this under the contributer's section at
> > http://tapestry.apache.org/community.html#Community-BecomingaContributor
> .
> > A new contributer like me can take advantage of this.
>
> "This information" referring to copyrights & licensing? Frankly, I
> don't think it belongs to the spot you pointed out. Perhaps something
> in http://www.apache.org/licenses/, but then again,
> http://www.apache.org/foundation/licence-FAQ.html (linked from the
> previous resource) does a decent job of answering the license
> questions. Do you think it'd be useful for linking these in from the
> community page? Maybe a separate "Read more about Apache" section?
>
> Kalle
>
>
> > On Thu, Jul 7, 2011 at 11:33 AM, Kalle Korhonen
> > <ka...@gmail.com>wrote:
> >
> >> On Wed, Jul 6, 2011 at 7:16 PM, dragan.sahpaskix@gmail.com
> >> <dr...@gmail.com> wrote:
> >> > On Wed, Jul 6, 2011 at 8:59 PM, Kalle Korhonen
> >> > <ka...@gmail.com>wrote:
> >> > - copyrights - have you copied any code/styles from anywhere you
> >> >> haven't written yourself?
> >> > Actually I also wanted to discuss this. I had looked at many css
> dropdown
> >> > menus, before doing it and the one I implemented is "inspired" by this
> >> > menu <
> >> http://www.lwis.net/free-css-drop-down-menu/dropdown.simple.linear.html
> >
> >> > which
> >> > is dual licenced <http://www.lwis.net/free-css-drop-down-menu/>
> (bottom
> >> of
> >> > page) under MIT <http://opensource.org/licenses/mit-license.php> and
> >> > GPL<http://www.gnu.org/copyleft/gpl.html> (I
> >> > know its not compatible with apache). But the thing is that Its not
> the
> >> same
> >> > CSS its still quite changed and I was not sure if I have reused and
> >> changed
> >> > it, or just written something new "inspired" by it :). I avoided doing
> >> > copy-> paste, I typed the CSS as I saw it best.
> >> > Anyway, please provide advice about this, that I will gladly accept,
> >> because
> >> > I don't have much experience dealing with licences and I want to avoid
> >> > making mistakes regarding this.
> >>
> >> I purposefully mentioned copyrights since the issue is separate from
> >> licensing. You did exactly the right thing by not copying, but rather
> >> re-creating it. Regardless of the license (unless the license
> >> explicitly forfeits copyrights), a piece of work is automatically
> >> covered by copyright laws practically anywhere in the world.
> >> Copyrights protect the "the form" of the work, i.e. the exact sequence
> >> of characters if it's a literature works. If you copy and modify, the
> >> question is whether you created on original work or if it's derivative
> >> work (compare for example to cases where photos are used as a basis
> >> for a poster - one famous case was of a stylized portrait of Barack
> >> Obama). If you independently created word for word the same literature
> >> works, piece of code, etc. you would still own the copyrights to it
> >> but it might be difficult to prove that you really came up with
> >> exactly the same as somebody before you if the said entity challenged
> >> you on that. Copyright issue is often neglected on the web since it's
> >> so easy to copy pieces of Javascript, CSS, etc. from anywhere, but in
> >> principle, when you are copying something, you are making a copyright
> >> infringement (unless it's a "fair use" - for example when you are
> >> quoting somebody). More at http://en.wikipedia.org/wiki/Copyright.
> >>
> >> As to the license issue, you are fine. I really don't want to hide
> >> behind the typical "I'm not a lawyer, you should consult with.." I'm
> >> of the the opinion that any software developer should have basic
> >> understanding of the most common open source licenses used today, and
> >> that reasonable people should be able to talk about legal issues in
> >> software without official qualifications (after all, nobody has an
> >> issue talking about football or some other sport even though very few
> >> of us are professional practitioners). MIT license
> >> (http://en.wikipedia.org/wiki/MIT_License) is fully compatible with
> >> Apache license (derivative works could be licensed under Apache
> >> license). Apache Software Foundation doesn't allow their projects to
> >> use any (L)GPL'd (or other copy-left licensed) code although from
> >> GPL's point of view, Apache licensed code is compatible depending on
> >> version (more at http://www.gnu.org/licenses/license-list.html).
> >> Anyway, licensing was never an issue in the first place; you would
> >> have first needed to use some copyrighted works which you didn't do.
> >> *Everything* is based on some previous work and knowledge, and
> >> licenses cannot be used to prohibit copying ideas or ways to make
> >> something work. Patents however, have much broader implications since
> >> they protect the idea rather than the form, but it's nearly impossible
> >> to tell if any of the ideas used here are protected by some patents
> >> (in all likelihood actually yes, but that's not something you need to
> >> consider). Hope that clears it up.
> >>
> >> >  - what's the wait for in onContextMenuFromGrid1(...) of the dropdown
> >> >> example?
> >> > I have just copied it from the grid examples. When working locally the
> >> ajax
> >> > is fast so I cannot see the "loading ..." text, that is why I put
> >> > Thread.sleep. Its just for the demo site it wont be in the tests.
> >>
> >> Ah, yes of course. I just wondered what the purpose was since I
> >> happened to notice it.
> >>
> >> Kalle
> >>
> >>
> >> >> > 2. Grid Enhancements - Making pagination and Sorting
> >> >> > Bookmarkable (see demo page)
> >> >> >  - This is achieved by modifying the existing GridColumns and
> >> >> GridPager (see
> >> >> > line 141) components with just a few lines of code, combined with
> >> mixins
> >> >> for
> >> >> > the actual URL manipulation (bookmarking).
> >> >> > - The main issue why I had to modify GridPager and GridColumns is
> >> because
> >> >> > they don't keep (off course) the URL parameters (request
> parameters)
> >> for
> >> >> the
> >> >> > links for the sort columns (in GridColumns) and for the links in
> the
> >> page
> >> >> > numbers (in Grid Pager). The added LOC are just to keep those
> >> parameters
> >> >> for
> >> >> > their action and sort events. This approach obviously needs
> >> rethinking.
> >> >> One
> >> >> > solution I could think of is decorating the links but this happens
> in
> >> >> pages
> >> >> > not components, so I would have to add advice to all pages (tried
> that
> >> >> also
> >> >> > and it worked), but it seems like just too much overhead.
> >> >> > - Another idea is to just make a redirect on setupRender on the
> grid's
> >> >> > mixins to put the parameters in the url. This is the simplest
> solution
> >> >> and
> >> >> > it would also work if the grid is sorted in code (not by clicking
> the
> >> >> > columns), but a redirect is another request. IDK if this can lead
> to
> >> >> usage
> >> >> > problems. Advice please :)
> >> >> > - So. All Work is done in the 2 mixins ColumnsSort.java (for Grid
> >> >> > Columns) and CurrentPageURL.java (for GridPager) that catch the
> sort
> >> and
> >> >> > action events and add parameters and also read parameters from the
> >> >> Request
> >> >> > to adjust column sorting and pagination. I supose this is quite ok.
> >> But
> >> >> the
> >> >> > main issue remains.
> >> >> > "How to keep the request parameters for the links produced by
> >> GridPager
> >> >> and
> >> >> > GridColumns?"
> >> >>
> >> >> Unfortunately, I don't have good suggestions for this at the moment.
> >> >> If it was possible to advice the component, it sounds like that could
> >> >> have been a good enough solution but I agree advising all pages is
> too
> >> >> heavyweight as a solution. For redirects, while it's reasonable safe
> >> >> to assume that the datamodel is backed by some cache, we cannot be
> >> >> sure and so might have an adverse effect on performance. I'll spend a
> >> >> bit more time on it to see if there are other reasonable
> alternatives.
> >> >>
> >> >
> >> > Yes, I have tried few (working) solutions but with just too much
> overhead
> >> on
> >> > advices etc.
> >> > I'm still searching for the best way to do it, even considering small
> >> > changes in the GridColumns and GridPager code. When I have something
> new
> >> for
> >> > this problem I'll post it here.
> >> >
> >> >
> >> >>
> >> >> > 3. Expose the cell content in GridCell.java
> >> >> >  - Another issue I was advised to look into by my mentor (Kalle) is
> to
> >> >> > replace the advice that makes ContextMenu.java work for the
> tapestry
> >> >> grid.
> >> >> > Basically this is the idea: Modify GridCell.java to expose the grid
> >> cell
> >> >> > contents (row value and property value not just property value like
> in
> >> >> > PropertyOutputContext.java) in an environmental. This can be used
> in
> >> far
> >> >> > more scenarios, not just contextmenu for the grid (think of a mixin
> >> that
> >> >> > selects a grid row (or cell) and notifies the server via ajax, so
> you
> >> can
> >> >> do
> >> >> > master-detail pages etc).
> >> >> > Replacing the GridCell advice with a few lines of code is next on
> my
> >> work
> >> >> > log so we'll se how it goes.
> >> >>
> >> >> Yes, this makes sense to me and it's fairly cheap to do.
> >> >
> >> >
> >> >> Kalle
> >> >>
> >> >
> >> > Cheers,
> >> > Dragan Sahpaski
> >> >
> >> >
> >> >>
> >> >>
> >> >> > On Wed, Jun 15, 2011 at 1:27 PM, dragan.sahpaskix@gmail.com
> >> >> > <dr...@gmail.com> wrote:
> >> >> >>
> >> >> >> Hi,
> >> >> >> I have updated the contextmenu with other client events like
> >> mousedown,
> >> >> >> mouseover etc. that you can look at on the new examples
> >> >> >> page http://dragansah.com/contextmenu/parametersexamples.
> >> >> >> You can browse the issues (mainly tasks and bugs)
> >> >> >> here
> >> >>
> >>
> http://code.google.com/a/apache-extras.org/p/right-click-menu-gsoc2011/issues/list
> >> >>  and
> >> >> >> if someone has some ideas or wishes, they can add them to the
> issues
> >> >> list.
> >> >> >> Next on my work-log is to provide a dropdown menu as a separate
> >> >> component
> >> >> >> that can be used with the existing contextmenu. It is not directly
> >> >> related
> >> >> >> to the contextmenu because you can put anything in the
> contextmenu,
> >> but
> >> >> >> maybe 90% of the use-cases of a contextmenu is to have a dropdown
> >> wiht
> >> >> icon
> >> >> >> and a label like they have on the rich faces demo site under
> >> >> >> RichMenu->ContextMenu.
> >> >> >> Any kind of comments or remarks are very much welcomed.
> >> >> >> Cheers,
> >> >> >> Dragan Sahpaski
> >> >> >>
> >> >> >>
> >> >> >> On Tue, May 31, 2011 at 7:16 PM, Kalle Korhonen
> >> >> >> <ka...@gmail.com> wrote:
> >> >> >>>
> >> >> >>> I'm officially Dragan's mentor but the rest of committers should
> >> >> >>> really take a look at Dragan's excellent work if you can just
> spare
> >> a
> >> >> >>> few cycles for it. The demo site (
> http://dragansah.com/contextmenu/
> >> )
> >> >> >>> Dragan put together makes it easy to track the project status
> even
> >> if
> >> >> >>> you don't have time to dive into the code. We already talked
> about
> >> the
> >> >> >>> items via Skype but a few quick comments below..
> >> >> >>>
> >> >> >>> On Sun, May 29, 2011 at 1:51 PM, dragan.sahpaskix@gmail.com
> >> >> >>> <dr...@gmail.com> wrote:
> >> >> >>> >   1. Two mixins: ContextMenu and ContextMenuAjax or merge them
> in
> >> one
> >> >> >>> >   mixin?
> >> >> >>>
> >> >> >>> It doesn't cost any more to use separate mixins for the user so
> >> >> >>> probably makes sense to keep as is for now.
> >> >> >>>
> >> >> >>> >   2. Is the concept of advising GridCell (actualy
> >> >> >>>
> >> >> >>> AbstractPropertyOutput<
> >> >>
> >>
> http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/corelib/base/AbstractPropertyOutput.html#renderPropertyValue(org.apache.tapestry5.MarkupWriter
> >> >> ,
> >> >> >>> >   java.lang.String)>) ok? Its clear that we cannot implement
> >> support
> >> >> of
> >> >> >>> > the
> >> >> >>> >   t5 grid without an advice or I'm I wrong?
> >> >> >>>
> >> >> >>> That's the way and it didn't seem too bad at all, but if it'd be
> >> >> >>> possible to implement it better by making a small, generic and
> >> >> >>> backwards compatible enhancement to GridCell, I think that'd be
> >> >> >>> preferable in the long run, just because there's some performance
> >> >> >>> penalty whenever using an advice, and an AbstractPropertyOutput
> gets
> >> >> >>> used a lot.
> >> >> >>>
> >> >> >>> >   5. The contextmenu is rendered after the component and there
> is
> >> a
> >> >> bit
> >> >> >>> > of
> >> >> >>> >   The quirk is that the contextmenu forces the render of the
> >> >> conainer's
> >> >> >>> >   clientId (if it is a t5 ClientElement), and uses it to set a
> >> >> >>> > javascript
> >> >> >>> >   event oncontextmenu on it using the id. If the component is
> not
> >> a
> >> >> t5
> >> >> >>> >   ClientElement (t5 Label for example), than this javascript is
> >> >> applied
> >> >> >>> > for
> >> >> >>> >   getting the client element in js:
> >> >> $('contextMenuId').previousSibling.
> >> >> >>> > This
> >> >> >>> >   code assumes that the parent component is only one html
> element
> >> >> (div
> >> >> >>> > or
> >> >> >>> >   similar), but this is not the case for example the t5
> TextField
> >> >> which
> >> >> >>> >   renders a trailing icon. Luckily the TextField is covered
> >> because
> >> >> it
> >> >> >>> > is a
> >> >> >>>
> >> >> >>> Seems to me it's quite fine to require ClientElement in that
> case.
> >> >> >>>
> >> >> >>> Kalle
> >> >> >>>
> >> >> >>>
> >> ---------------------------------------------------------------------
> >> >> >>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> >> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >> >> >>>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>

Re: GSOC Right Click Menu

Posted by Kalle Korhonen <ka...@gmail.com>.

On Wed, Jul 6, 2011 at 11:14 PM, Taha Hafeez <ta...@gmail.com> wrote:
> Thanks for sharing this information. It would be great if you find time to
> place this under the contributer's section at
> http://tapestry.apache.org/community.html#Community-BecomingaContributor.
> A new contributer like me can take advantage of this.

"This information" referring to copyrights & licensing? Frankly, I
don't think it belongs to the spot you pointed out. Perhaps something
in http://www.apache.org/licenses/, but then again,
http://www.apache.org/foundation/licence-FAQ.html (linked from the
previous resource) does a decent job of answering the license
questions. Do you think it'd be useful for linking these in from the
community page? Maybe a separate "Read more about Apache" section?

Kalle


> On Thu, Jul 7, 2011 at 11:33 AM, Kalle Korhonen
> <ka...@gmail.com>wrote:
>
>> On Wed, Jul 6, 2011 at 7:16 PM, dragan.sahpaskix@gmail.com
>> <dr...@gmail.com> wrote:
>> > On Wed, Jul 6, 2011 at 8:59 PM, Kalle Korhonen
>> > <ka...@gmail.com>wrote:
>> > - copyrights - have you copied any code/styles from anywhere you
>> >> haven't written yourself?
>> > Actually I also wanted to discuss this. I had looked at many css dropdown
>> > menus, before doing it and the one I implemented is "inspired" by this
>> > menu <
>> http://www.lwis.net/free-css-drop-down-menu/dropdown.simple.linear.html>
>> > which
>> > is dual licenced <http://www.lwis.net/free-css-drop-down-menu/> (bottom
>> of
>> > page) under MIT <http://opensource.org/licenses/mit-license.php> and
>> > GPL<http://www.gnu.org/copyleft/gpl.html> (I
>> > know its not compatible with apache). But the thing is that Its not the
>> same
>> > CSS its still quite changed and I was not sure if I have reused and
>> changed
>> > it, or just written something new "inspired" by it :). I avoided doing
>> > copy-> paste, I typed the CSS as I saw it best.
>> > Anyway, please provide advice about this, that I will gladly accept,
>> because
>> > I don't have much experience dealing with licences and I want to avoid
>> > making mistakes regarding this.
>>
>> I purposefully mentioned copyrights since the issue is separate from
>> licensing. You did exactly the right thing by not copying, but rather
>> re-creating it. Regardless of the license (unless the license
>> explicitly forfeits copyrights), a piece of work is automatically
>> covered by copyright laws practically anywhere in the world.
>> Copyrights protect the "the form" of the work, i.e. the exact sequence
>> of characters if it's a literature works. If you copy and modify, the
>> question is whether you created on original work or if it's derivative
>> work (compare for example to cases where photos are used as a basis
>> for a poster - one famous case was of a stylized portrait of Barack
>> Obama). If you independently created word for word the same literature
>> works, piece of code, etc. you would still own the copyrights to it
>> but it might be difficult to prove that you really came up with
>> exactly the same as somebody before you if the said entity challenged
>> you on that. Copyright issue is often neglected on the web since it's
>> so easy to copy pieces of Javascript, CSS, etc. from anywhere, but in
>> principle, when you are copying something, you are making a copyright
>> infringement (unless it's a "fair use" - for example when you are
>> quoting somebody). More at http://en.wikipedia.org/wiki/Copyright.
>>
>> As to the license issue, you are fine. I really don't want to hide
>> behind the typical "I'm not a lawyer, you should consult with.." I'm
>> of the the opinion that any software developer should have basic
>> understanding of the most common open source licenses used today, and
>> that reasonable people should be able to talk about legal issues in
>> software without official qualifications (after all, nobody has an
>> issue talking about football or some other sport even though very few
>> of us are professional practitioners). MIT license
>> (http://en.wikipedia.org/wiki/MIT_License) is fully compatible with
>> Apache license (derivative works could be licensed under Apache
>> license). Apache Software Foundation doesn't allow their projects to
>> use any (L)GPL'd (or other copy-left licensed) code although from
>> GPL's point of view, Apache licensed code is compatible depending on
>> version (more at http://www.gnu.org/licenses/license-list.html).
>> Anyway, licensing was never an issue in the first place; you would
>> have first needed to use some copyrighted works which you didn't do.
>> *Everything* is based on some previous work and knowledge, and
>> licenses cannot be used to prohibit copying ideas or ways to make
>> something work. Patents however, have much broader implications since
>> they protect the idea rather than the form, but it's nearly impossible
>> to tell if any of the ideas used here are protected by some patents
>> (in all likelihood actually yes, but that's not something you need to
>> consider). Hope that clears it up.
>>
>> >  - what's the wait for in onContextMenuFromGrid1(...) of the dropdown
>> >> example?
>> > I have just copied it from the grid examples. When working locally the
>> ajax
>> > is fast so I cannot see the "loading ..." text, that is why I put
>> > Thread.sleep. Its just for the demo site it wont be in the tests.
>>
>> Ah, yes of course. I just wondered what the purpose was since I
>> happened to notice it.
>>
>> Kalle
>>
>>
>> >> > 2. Grid Enhancements - Making pagination and Sorting
>> >> > Bookmarkable (see demo page)
>> >> >  - This is achieved by modifying the existing GridColumns and
>> >> GridPager (see
>> >> > line 141) components with just a few lines of code, combined with
>> mixins
>> >> for
>> >> > the actual URL manipulation (bookmarking).
>> >> > - The main issue why I had to modify GridPager and GridColumns is
>> because
>> >> > they don't keep (off course) the URL parameters (request parameters)
>> for
>> >> the
>> >> > links for the sort columns (in GridColumns) and for the links in the
>> page
>> >> > numbers (in Grid Pager). The added LOC are just to keep those
>> parameters
>> >> for
>> >> > their action and sort events. This approach obviously needs
>> rethinking.
>> >> One
>> >> > solution I could think of is decorating the links but this happens in
>> >> pages
>> >> > not components, so I would have to add advice to all pages (tried that
>> >> also
>> >> > and it worked), but it seems like just too much overhead.
>> >> > - Another idea is to just make a redirect on setupRender on the grid's
>> >> > mixins to put the parameters in the url. This is the simplest solution
>> >> and
>> >> > it would also work if the grid is sorted in code (not by clicking the
>> >> > columns), but a redirect is another request. IDK if this can lead to
>> >> usage
>> >> > problems. Advice please :)
>> >> > - So. All Work is done in the 2 mixins ColumnsSort.java (for Grid
>> >> > Columns) and CurrentPageURL.java (for GridPager) that catch the sort
>> and
>> >> > action events and add parameters and also read parameters from the
>> >> Request
>> >> > to adjust column sorting and pagination. I supose this is quite ok.
>> But
>> >> the
>> >> > main issue remains.
>> >> > "How to keep the request parameters for the links produced by
>> GridPager
>> >> and
>> >> > GridColumns?"
>> >>
>> >> Unfortunately, I don't have good suggestions for this at the moment.
>> >> If it was possible to advice the component, it sounds like that could
>> >> have been a good enough solution but I agree advising all pages is too
>> >> heavyweight as a solution. For redirects, while it's reasonable safe
>> >> to assume that the datamodel is backed by some cache, we cannot be
>> >> sure and so might have an adverse effect on performance. I'll spend a
>> >> bit more time on it to see if there are other reasonable alternatives.
>> >>
>> >
>> > Yes, I have tried few (working) solutions but with just too much overhead
>> on
>> > advices etc.
>> > I'm still searching for the best way to do it, even considering small
>> > changes in the GridColumns and GridPager code. When I have something new
>> for
>> > this problem I'll post it here.
>> >
>> >
>> >>
>> >> > 3. Expose the cell content in GridCell.java
>> >> >  - Another issue I was advised to look into by my mentor (Kalle) is to
>> >> > replace the advice that makes ContextMenu.java work for the tapestry
>> >> grid.
>> >> > Basically this is the idea: Modify GridCell.java to expose the grid
>> cell
>> >> > contents (row value and property value not just property value like in
>> >> > PropertyOutputContext.java) in an environmental. This can be used in
>> far
>> >> > more scenarios, not just contextmenu for the grid (think of a mixin
>> that
>> >> > selects a grid row (or cell) and notifies the server via ajax, so you
>> can
>> >> do
>> >> > master-detail pages etc).
>> >> > Replacing the GridCell advice with a few lines of code is next on my
>> work
>> >> > log so we'll se how it goes.
>> >>
>> >> Yes, this makes sense to me and it's fairly cheap to do.
>> >
>> >
>> >> Kalle
>> >>
>> >
>> > Cheers,
>> > Dragan Sahpaski
>> >
>> >
>> >>
>> >>
>> >> > On Wed, Jun 15, 2011 at 1:27 PM, dragan.sahpaskix@gmail.com
>> >> > <dr...@gmail.com> wrote:
>> >> >>
>> >> >> Hi,
>> >> >> I have updated the contextmenu with other client events like
>> mousedown,
>> >> >> mouseover etc. that you can look at on the new examples
>> >> >> page http://dragansah.com/contextmenu/parametersexamples.
>> >> >> You can browse the issues (mainly tasks and bugs)
>> >> >> here
>> >>
>> http://code.google.com/a/apache-extras.org/p/right-click-menu-gsoc2011/issues/list
>> >>  and
>> >> >> if someone has some ideas or wishes, they can add them to the issues
>> >> list.
>> >> >> Next on my work-log is to provide a dropdown menu as a separate
>> >> component
>> >> >> that can be used with the existing contextmenu. It is not directly
>> >> related
>> >> >> to the contextmenu because you can put anything in the contextmenu,
>> but
>> >> >> maybe 90% of the use-cases of a contextmenu is to have a dropdown
>> wiht
>> >> icon
>> >> >> and a label like they have on the rich faces demo site under
>> >> >> RichMenu->ContextMenu.
>> >> >> Any kind of comments or remarks are very much welcomed.
>> >> >> Cheers,
>> >> >> Dragan Sahpaski
>> >> >>
>> >> >>
>> >> >> On Tue, May 31, 2011 at 7:16 PM, Kalle Korhonen
>> >> >> <ka...@gmail.com> wrote:
>> >> >>>
>> >> >>> I'm officially Dragan's mentor but the rest of committers should
>> >> >>> really take a look at Dragan's excellent work if you can just spare
>> a
>> >> >>> few cycles for it. The demo site (http://dragansah.com/contextmenu/
>> )
>> >> >>> Dragan put together makes it easy to track the project status even
>> if
>> >> >>> you don't have time to dive into the code. We already talked about
>> the
>> >> >>> items via Skype but a few quick comments below..
>> >> >>>
>> >> >>> On Sun, May 29, 2011 at 1:51 PM, dragan.sahpaskix@gmail.com
>> >> >>> <dr...@gmail.com> wrote:
>> >> >>> >   1. Two mixins: ContextMenu and ContextMenuAjax or merge them in
>> one
>> >> >>> >   mixin?
>> >> >>>
>> >> >>> It doesn't cost any more to use separate mixins for the user so
>> >> >>> probably makes sense to keep as is for now.
>> >> >>>
>> >> >>> >   2. Is the concept of advising GridCell (actualy
>> >> >>>
>> >> >>> AbstractPropertyOutput<
>> >>
>> http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/corelib/base/AbstractPropertyOutput.html#renderPropertyValue(org.apache.tapestry5.MarkupWriter
>> >> ,
>> >> >>> >   java.lang.String)>) ok? Its clear that we cannot implement
>> support
>> >> of
>> >> >>> > the
>> >> >>> >   t5 grid without an advice or I'm I wrong?
>> >> >>>
>> >> >>> That's the way and it didn't seem too bad at all, but if it'd be
>> >> >>> possible to implement it better by making a small, generic and
>> >> >>> backwards compatible enhancement to GridCell, I think that'd be
>> >> >>> preferable in the long run, just because there's some performance
>> >> >>> penalty whenever using an advice, and an AbstractPropertyOutput gets
>> >> >>> used a lot.
>> >> >>>
>> >> >>> >   5. The contextmenu is rendered after the component and there is
>> a
>> >> bit
>> >> >>> > of
>> >> >>> >   The quirk is that the contextmenu forces the render of the
>> >> conainer's
>> >> >>> >   clientId (if it is a t5 ClientElement), and uses it to set a
>> >> >>> > javascript
>> >> >>> >   event oncontextmenu on it using the id. If the component is not
>> a
>> >> t5
>> >> >>> >   ClientElement (t5 Label for example), than this javascript is
>> >> applied
>> >> >>> > for
>> >> >>> >   getting the client element in js:
>> >> $('contextMenuId').previousSibling.
>> >> >>> > This
>> >> >>> >   code assumes that the parent component is only one html element
>> >> (div
>> >> >>> > or
>> >> >>> >   similar), but this is not the case for example the t5 TextField
>> >> which
>> >> >>> >   renders a trailing icon. Luckily the TextField is covered
>> because
>> >> it
>> >> >>> > is a
>> >> >>>
>> >> >>> Seems to me it's quite fine to require ClientElement in that case.
>> >> >>>
>> >> >>> Kalle
>> >> >>>
>> >> >>>
>> ---------------------------------------------------------------------
>> >> >>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> >> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
>> >> >>>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: dev-help@tapestry.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: GSOC Right Click Menu

Posted by Taha Hafeez <ta...@gmail.com>.

Hi Kalle

Thanks for sharing this information. It would be great if you find time to
place this under the contributer's section at
http://tapestry.apache.org/community.html#Community-BecomingaContributor.

A new contributer like me can take advantage of this.

regards
Taha


On Thu, Jul 7, 2011 at 11:33 AM, Kalle Korhonen
<ka...@gmail.com>wrote:

> On Wed, Jul 6, 2011 at 7:16 PM, dragan.sahpaskix@gmail.com
> <dr...@gmail.com> wrote:
> > On Wed, Jul 6, 2011 at 8:59 PM, Kalle Korhonen
> > <ka...@gmail.com>wrote:
> > - copyrights - have you copied any code/styles from anywhere you
> >> haven't written yourself?
> > Actually I also wanted to discuss this. I had looked at many css dropdown
> > menus, before doing it and the one I implemented is "inspired" by this
> > menu <
> http://www.lwis.net/free-css-drop-down-menu/dropdown.simple.linear.html>
> > which
> > is dual licenced <http://www.lwis.net/free-css-drop-down-menu/> (bottom
> of
> > page) under MIT <http://opensource.org/licenses/mit-license.php> and
> > GPL<http://www.gnu.org/copyleft/gpl.html> (I
> > know its not compatible with apache). But the thing is that Its not the
> same
> > CSS its still quite changed and I was not sure if I have reused and
> changed
> > it, or just written something new "inspired" by it :). I avoided doing
> > copy-> paste, I typed the CSS as I saw it best.
> > Anyway, please provide advice about this, that I will gladly accept,
> because
> > I don't have much experience dealing with licences and I want to avoid
> > making mistakes regarding this.
>
> I purposefully mentioned copyrights since the issue is separate from
> licensing. You did exactly the right thing by not copying, but rather
> re-creating it. Regardless of the license (unless the license
> explicitly forfeits copyrights), a piece of work is automatically
> covered by copyright laws practically anywhere in the world.
> Copyrights protect the "the form" of the work, i.e. the exact sequence
> of characters if it's a literature works. If you copy and modify, the
> question is whether you created on original work or if it's derivative
> work (compare for example to cases where photos are used as a basis
> for a poster - one famous case was of a stylized portrait of Barack
> Obama). If you independently created word for word the same literature
> works, piece of code, etc. you would still own the copyrights to it
> but it might be difficult to prove that you really came up with
> exactly the same as somebody before you if the said entity challenged
> you on that. Copyright issue is often neglected on the web since it's
> so easy to copy pieces of Javascript, CSS, etc. from anywhere, but in
> principle, when you are copying something, you are making a copyright
> infringement (unless it's a "fair use" - for example when you are
> quoting somebody). More at http://en.wikipedia.org/wiki/Copyright.
>
> As to the license issue, you are fine. I really don't want to hide
> behind the typical "I'm not a lawyer, you should consult with.." I'm
> of the the opinion that any software developer should have basic
> understanding of the most common open source licenses used today, and
> that reasonable people should be able to talk about legal issues in
> software without official qualifications (after all, nobody has an
> issue talking about football or some other sport even though very few
> of us are professional practitioners). MIT license
> (http://en.wikipedia.org/wiki/MIT_License) is fully compatible with
> Apache license (derivative works could be licensed under Apache
> license). Apache Software Foundation doesn't allow their projects to
> use any (L)GPL'd (or other copy-left licensed) code although from
> GPL's point of view, Apache licensed code is compatible depending on
> version (more at http://www.gnu.org/licenses/license-list.html).
> Anyway, licensing was never an issue in the first place; you would
> have first needed to use some copyrighted works which you didn't do.
> *Everything* is based on some previous work and knowledge, and
> licenses cannot be used to prohibit copying ideas or ways to make
> something work. Patents however, have much broader implications since
> they protect the idea rather than the form, but it's nearly impossible
> to tell if any of the ideas used here are protected by some patents
> (in all likelihood actually yes, but that's not something you need to
> consider). Hope that clears it up.
>
> >  - what's the wait for in onContextMenuFromGrid1(...) of the dropdown
> >> example?
> > I have just copied it from the grid examples. When working locally the
> ajax
> > is fast so I cannot see the "loading ..." text, that is why I put
> > Thread.sleep. Its just for the demo site it wont be in the tests.
>
> Ah, yes of course. I just wondered what the purpose was since I
> happened to notice it.
>
> Kalle
>
>
> >> > 2. Grid Enhancements - Making pagination and Sorting
> >> > Bookmarkable (see demo page)
> >> >  - This is achieved by modifying the existing GridColumns and
> >> GridPager (see
> >> > line 141) components with just a few lines of code, combined with
> mixins
> >> for
> >> > the actual URL manipulation (bookmarking).
> >> > - The main issue why I had to modify GridPager and GridColumns is
> because
> >> > they don't keep (off course) the URL parameters (request parameters)
> for
> >> the
> >> > links for the sort columns (in GridColumns) and for the links in the
> page
> >> > numbers (in Grid Pager). The added LOC are just to keep those
> parameters
> >> for
> >> > their action and sort events. This approach obviously needs
> rethinking.
> >> One
> >> > solution I could think of is decorating the links but this happens in
> >> pages
> >> > not components, so I would have to add advice to all pages (tried that
> >> also
> >> > and it worked), but it seems like just too much overhead.
> >> > - Another idea is to just make a redirect on setupRender on the grid's
> >> > mixins to put the parameters in the url. This is the simplest solution
> >> and
> >> > it would also work if the grid is sorted in code (not by clicking the
> >> > columns), but a redirect is another request. IDK if this can lead to
> >> usage
> >> > problems. Advice please :)
> >> > - So. All Work is done in the 2 mixins ColumnsSort.java (for Grid
> >> > Columns) and CurrentPageURL.java (for GridPager) that catch the sort
> and
> >> > action events and add parameters and also read parameters from the
> >> Request
> >> > to adjust column sorting and pagination. I supose this is quite ok.
> But
> >> the
> >> > main issue remains.
> >> > "How to keep the request parameters for the links produced by
> GridPager
> >> and
> >> > GridColumns?"
> >>
> >> Unfortunately, I don't have good suggestions for this at the moment.
> >> If it was possible to advice the component, it sounds like that could
> >> have been a good enough solution but I agree advising all pages is too
> >> heavyweight as a solution. For redirects, while it's reasonable safe
> >> to assume that the datamodel is backed by some cache, we cannot be
> >> sure and so might have an adverse effect on performance. I'll spend a
> >> bit more time on it to see if there are other reasonable alternatives.
> >>
> >
> > Yes, I have tried few (working) solutions but with just too much overhead
> on
> > advices etc.
> > I'm still searching for the best way to do it, even considering small
> > changes in the GridColumns and GridPager code. When I have something new
> for
> > this problem I'll post it here.
> >
> >
> >>
> >> > 3. Expose the cell content in GridCell.java
> >> >  - Another issue I was advised to look into by my mentor (Kalle) is to
> >> > replace the advice that makes ContextMenu.java work for the tapestry
> >> grid.
> >> > Basically this is the idea: Modify GridCell.java to expose the grid
> cell
> >> > contents (row value and property value not just property value like in
> >> > PropertyOutputContext.java) in an environmental. This can be used in
> far
> >> > more scenarios, not just contextmenu for the grid (think of a mixin
> that
> >> > selects a grid row (or cell) and notifies the server via ajax, so you
> can
> >> do
> >> > master-detail pages etc).
> >> > Replacing the GridCell advice with a few lines of code is next on my
> work
> >> > log so we'll se how it goes.
> >>
> >> Yes, this makes sense to me and it's fairly cheap to do.
> >
> >
> >> Kalle
> >>
> >
> > Cheers,
> > Dragan Sahpaski
> >
> >
> >>
> >>
> >> > On Wed, Jun 15, 2011 at 1:27 PM, dragan.sahpaskix@gmail.com
> >> > <dr...@gmail.com> wrote:
> >> >>
> >> >> Hi,
> >> >> I have updated the contextmenu with other client events like
> mousedown,
> >> >> mouseover etc. that you can look at on the new examples
> >> >> page http://dragansah.com/contextmenu/parametersexamples.
> >> >> You can browse the issues (mainly tasks and bugs)
> >> >> here
> >>
> http://code.google.com/a/apache-extras.org/p/right-click-menu-gsoc2011/issues/list
> >>  and
> >> >> if someone has some ideas or wishes, they can add them to the issues
> >> list.
> >> >> Next on my work-log is to provide a dropdown menu as a separate
> >> component
> >> >> that can be used with the existing contextmenu. It is not directly
> >> related
> >> >> to the contextmenu because you can put anything in the contextmenu,
> but
> >> >> maybe 90% of the use-cases of a contextmenu is to have a dropdown
> wiht
> >> icon
> >> >> and a label like they have on the rich faces demo site under
> >> >> RichMenu->ContextMenu.
> >> >> Any kind of comments or remarks are very much welcomed.
> >> >> Cheers,
> >> >> Dragan Sahpaski
> >> >>
> >> >>
> >> >> On Tue, May 31, 2011 at 7:16 PM, Kalle Korhonen
> >> >> <ka...@gmail.com> wrote:
> >> >>>
> >> >>> I'm officially Dragan's mentor but the rest of committers should
> >> >>> really take a look at Dragan's excellent work if you can just spare
> a
> >> >>> few cycles for it. The demo site (http://dragansah.com/contextmenu/
> )
> >> >>> Dragan put together makes it easy to track the project status even
> if
> >> >>> you don't have time to dive into the code. We already talked about
> the
> >> >>> items via Skype but a few quick comments below..
> >> >>>
> >> >>> On Sun, May 29, 2011 at 1:51 PM, dragan.sahpaskix@gmail.com
> >> >>> <dr...@gmail.com> wrote:
> >> >>> >   1. Two mixins: ContextMenu and ContextMenuAjax or merge them in
> one
> >> >>> >   mixin?
> >> >>>
> >> >>> It doesn't cost any more to use separate mixins for the user so
> >> >>> probably makes sense to keep as is for now.
> >> >>>
> >> >>> >   2. Is the concept of advising GridCell (actualy
> >> >>>
> >> >>> AbstractPropertyOutput<
> >>
> http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/corelib/base/AbstractPropertyOutput.html#renderPropertyValue(org.apache.tapestry5.MarkupWriter
> >> ,
> >> >>> >   java.lang.String)>) ok? Its clear that we cannot implement
> support
> >> of
> >> >>> > the
> >> >>> >   t5 grid without an advice or I'm I wrong?
> >> >>>
> >> >>> That's the way and it didn't seem too bad at all, but if it'd be
> >> >>> possible to implement it better by making a small, generic and
> >> >>> backwards compatible enhancement to GridCell, I think that'd be
> >> >>> preferable in the long run, just because there's some performance
> >> >>> penalty whenever using an advice, and an AbstractPropertyOutput gets
> >> >>> used a lot.
> >> >>>
> >> >>> >   5. The contextmenu is rendered after the component and there is
> a
> >> bit
> >> >>> > of
> >> >>> >   The quirk is that the contextmenu forces the render of the
> >> conainer's
> >> >>> >   clientId (if it is a t5 ClientElement), and uses it to set a
> >> >>> > javascript
> >> >>> >   event oncontextmenu on it using the id. If the component is not
> a
> >> t5
> >> >>> >   ClientElement (t5 Label for example), than this javascript is
> >> applied
> >> >>> > for
> >> >>> >   getting the client element in js:
> >> $('contextMenuId').previousSibling.
> >> >>> > This
> >> >>> >   code assumes that the parent component is only one html element
> >> (div
> >> >>> > or
> >> >>> >   similar), but this is not the case for example the t5 TextField
> >> which
> >> >>> >   renders a trailing icon. Luckily the TextField is covered
> because
> >> it
> >> >>> > is a
> >> >>>
> >> >>> Seems to me it's quite fine to require ClientElement in that case.
> >> >>>
> >> >>> Kalle
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> >>> For additional commands, e-mail: dev-help@tapestry.apache.org
> >> >>>
> >> >>
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>