On Wed, Jul 6, 2011 at 11:14 PM, Taha Hafeez <[email protected]> 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 > <[email protected]>wrote: > >> On Wed, Jul 6, 2011 at 7:16 PM, [email protected] >> <[email protected]> wrote: >> > On Wed, Jul 6, 2011 at 8:59 PM, Kalle Korhonen >> > <[email protected]>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, [email protected] >> >> > <[email protected]> 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 >> >> >> <[email protected]> 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, [email protected] >> >> >>> <[email protected]> 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: [email protected] >> >> >>> For additional commands, e-mail: [email protected] >> >> >>> >> >> >> >> >> > >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
