From photark-dev-return-1012-apmail-incubator-photark-dev-archive=incubator.apache.org@incubator.apache.org Mon Oct 11 04:15:06 2010 Return-Path: Delivered-To: apmail-incubator-photark-dev-archive@minotaur.apache.org Received: (qmail 37166 invoked from network); 11 Oct 2010 04:15:06 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 11 Oct 2010 04:15:06 -0000 Received: (qmail 80527 invoked by uid 500); 11 Oct 2010 04:15:06 -0000 Delivered-To: apmail-incubator-photark-dev-archive@incubator.apache.org Received: (qmail 80491 invoked by uid 500); 11 Oct 2010 04:15:05 -0000 Mailing-List: contact photark-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: photark-dev@incubator.apache.org Delivered-To: mailing list photark-dev@incubator.apache.org Received: (qmail 80483 invoked by uid 99); 11 Oct 2010 04:15:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 04:15:04 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of luckbr1975@gmail.com designates 209.85.214.175 as permitted sender) Received: from [209.85.214.175] (HELO mail-iw0-f175.google.com) (209.85.214.175) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 04:15:00 +0000 Received: by iwn7 with SMTP id 7so2193903iwn.6 for ; Sun, 10 Oct 2010 21:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=uDFBJyjDSNPmB9qcYhrkwq1UtO9avkfnuLsZEyWziWw=; b=rgGtWLr64exlW3RMQjtgohe3kE6WLWZDrndG+70JNWH3s043r8RFIwvV4dpPJOnUTi W9gkXo1rVAhJJkQDrlVkwGONwul5hwiqQofaWos7GdudN1CZPWC5kf2H5pWP+vkaEirm rRcmqc4zfpL5hh3m8VX1+rEujxBAiyyGO+wcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ehpOaUifOdiMQrU6IV/g9tLuvZrmPdA3o3kF4HIGUw6pr4IyNAIfQwgYwrQxcBjo6L pJiIMyYk4tVpJ6BWi49hR9RLMrm7pdUKotMR+FyNAqr3fyEn5lHuWf1WJcTgF0yVi8rc /aSJUb59fjUGsiMT+UH3znE2tociRACOZoDQs= MIME-Version: 1.0 Received: by 10.231.35.138 with SMTP id p10mr4326750ibd.33.1286770479723; Sun, 10 Oct 2010 21:14:39 -0700 (PDT) Received: by 10.231.115.155 with HTTP; Sun, 10 Oct 2010 21:14:39 -0700 (PDT) Date: Sun, 10 Oct 2010 21:14:39 -0700 Message-ID: Subject: Subscription UI, was Re: [jira] Created: (PHOTARK-62) UI support to subscribe external albums From: Luciano Resende To: photark-dev@incubator.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Oct 10, 2010 at 4:20 PM, Luciano Resende wro= te: > On Sun, Oct 10, 2010 at 12:03 PM, Subash Chaturanga = wrote: >> Hi all , >> >> On Thu, Oct 7, 2010 at 1:47 PM, Avdhesh Yadav wro= te: >> >>> check this thread. >>> http://www.mail-archive.com/photark-dev@incubator.apache.org/msg00784.h= tml >> >> >> The first patch i submitted stores each subscribed albums in a java >> collection .So based on that, for the next step, I went through the abov= e >> discussion and what i feel was to store the meta data >> (location,name,description) of images in a JCR node. As, a JCR =C2=A0pro= perty can >> hold multiple values, I think we can store each album as a property and = we >> can have two nodes for flicker and picasa . So that when we want to show >> them in gallery we can retrieve those data and on the fly create albums = and >> show them in the gallery. I would like to know, if anything wrong with t= his >> approach or is there any better way to do this? >> >> >> >> > > I'd recommend following the same node structure as the "local JCR" > albums, which the exception that when it's a subscription, the actual > image is stored remotely and we only have it's URL. > I was taking a look at the latest patch, and I'd have couple suggestions to the Subscription UI: 1) Today for the upload ui, a user can choose a "New Album" or select an existing album. How about we just create a new entry "New Remote Album" for the Picasa or Flickr albums, and then show required fields like : type (Picasa, Flickr, or anything new we might have) and then the URL, username and password ? 2) Both upload.html and upload.js seems to have specific fields to picasa_xxxx. This will not scale when we add support for different types of remote albums. We should just make generic fields like album_remote_url, album_remote_user, etc and use those independent of the type of remote album that is being added to the gallery 3) It seems that subscription is actually working, but the ui is acting a little weird as it seems to have succeeded adding the new remote album, but it then stays on the same page with the fields all populated as if a error had happened. 4) When I go back to albums view, it does not show any of the remote albums. Is that part supposed to be working already ? I'll look in the backend part later on when I find more time :) --=20 Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/