[development] joining irc group
marcvangend
info at marcvangend.nl
Tue Dec 1 12:22:01 UTC 2009
Visnu,
You can simply join the channels. See http://drupal.org/irc for an
overview of available channels and make sure to choose the most
appropriate channel for your needs.
Marc
PS When replying to the mailing list, please quote as little as possible.
vishnu vardhan wrote:
> Hi All ,
> Can i join #drupal chaneel or do i need recomendation???
> Visnu
>
> On Tue, Dec 1, 2009 at 5:10 PM, <development-request at drupal.org
> <mailto:development-request at drupal.org>> wrote:
>
> Send development mailing list submissions to
> development at drupal.org <mailto:development at drupal.org>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.drupal.org/mailman/listinfo/development
> or, via email, send a message with subject or body 'help' to
> development-request at drupal.org
> <mailto:development-request at drupal.org>
>
> You can reach the person managing the list at
> development-owner at drupal.org
> <mailto:development-owner at drupal.org>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of development digest..."
>
>
> Today's Topics:
>
> 1. Consolidating duplicate contrib modules for D7 (Brian Vuyk)
> 2. Re: Consolidating duplicate contrib modules for D7 (Andrew Berry)
> 3. Re: Ctools form wizard (Earl Miles)
> 4. Re: Consolidating duplicate contrib modules for D7 (Shai Gluskin)
> 5. alter theme registry, but only for some themes. possible?
> (David Cohen)
> 6. Re: Consolidating duplicate contrib modules for D7
> (Martin Stadler)
> 7. Re: Consolidating duplicate contrib modules for D7 (Zoltan
> Varady)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 30 Nov 2009 14:44:58 -0500
> From: Brian Vuyk <brian at brianvuyk.com <mailto:brian at brianvuyk.com>>
> Subject: [development] Consolidating duplicate contrib modules for D7
> To: development at drupal.org <mailto:development at drupal.org>
> Message-ID: <4B1420BA.7010404 at brianvuyk.com
> <mailto:4B1420BA.7010404 at brianvuyk.com>>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I know the whole 'duplication in contrib' issue has been discussed to
> death on this list, so I will try to keep this short.
>
> Obviously, the duplication in contrib is something we are working hard
> as a community to avoid. Nevertheless, in some cases, duplication has
> still crept in, and this leads to a poorer user experience, and user
> confusion.
>
> One prime example is the node access modules, which all perform nearly
> identical functions with more or less polish:
>
> Node Access: http://drupal.org/project/node_access
> Nodeaccess: http://drupal.org/project/nodeaccess
> Content Access: http://drupal.org/project/content_access
>
> Now, is there anything we as a community can do to clean up this
> sort of
> issue in contrib? I realize that in individual cases, the best
> policy is
> to post in the issue queues for the individual projects, but on a
> larger
> scale, is it worth starting something along the lines of #D7CX to
> consolidate the dupes in the name of a better user experience?
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 30 Nov 2009 15:22:55 -0500
> From: Andrew Berry <andrewberry at sentex.net
> <mailto:andrewberry at sentex.net>>
> Subject: Re: [development] Consolidating duplicate contrib modules for
> D7
> To: development at drupal.org <mailto:development at drupal.org>
> Message-ID: <53A37D3A-8063-4E4A-B679-19689DCE51E7 at sentex.net
> <mailto:53A37D3A-8063-4E4A-B679-19689DCE51E7 at sentex.net>>
> Content-Type: text/plain; charset="us-ascii"
>
> On 2009-11-30, at 2:44 PM, Brian Vuyk wrote:
>
> > Node Access: http://drupal.org/project/node_access
> > Nodeaccess: http://drupal.org/project/nodeaccess
>
> IMO there should be a CVS policy disallowing namespaces to be
> differentiated with dashes, underscores, spaces, and so on. This
> is a perfect example of the confusion this can cause.
>
> > is it worth starting something along the lines of #D7CX to
> consolidate the dupes in the name of a better user experience?
>
> I think that if this is something you want to do, you should try
> and find some of the more popular maintained modules and try to
> get one or two sets of projects on board. Once there are a few big
> projects starting down this path, I think it would really help to
> encourage the smaller projects to work together.
>
> --Andrew
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 2676 bytes
> Desc: not available
> Url :
> http://lists.drupal.org/pipermail/development/attachments/20091130/4ee3aa0c/attachment-0001.bin
>
> ------------------------------
>
> Message: 3
> Date: Mon, 30 Nov 2009 12:33:35 -0800
> From: Earl Miles <merlin at logrus.com <mailto:merlin at logrus.com>>
> Subject: Re: [development] Ctools form wizard
> To: development at drupal.org <mailto:development at drupal.org>
> Message-ID: <4B142C1F.7040006 at logrus.com
> <mailto:4B142C1F.7040006 at logrus.com>>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Dipen wrote:
> > Hi list,
> >
> > Can I mix system form with a custom form in ctools form wizard,
> I wish
> > to create a wizard containing 1 node add form and 2 custom
> forms. I have
> > briefly looked at advanced help of form wizard and I think there
> would
> > be problem in dealing with _submit of node add form in module
> space. Has
> > anyone encountered this before? I am trying to create multistep form
> > with 1 node add form and 2 custom forms and ctools looks like the
> > cleanest way but not sure how would I get around the _submit handler
> > problem for node add form.
> >
> > From ctools help:
> >
> > " The primary difference between these forms and a normal Drupal
> form is
> > that the submit handler should not save any data. Instead, it should
> > make any changes to a cached object (usually placed on the
> $form_state)
> > and only the _finish or _return handler should actually save any
> real
> > data. "
>
> Run in fear!
>
> What you want to do is really really hard, especially when dealing
> with
> nodes, because the node form is a *very* difficult workflow that
> is not
> really open to being changed. I don't think the ctools wizard is going
> to help you here. That said, at one point Nick Lewis was doing
> some work
> trying to integrate form wizard into the node form, and he had some
> success, but I haven't seen any movement there for a long time.
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 30 Nov 2009 15:50:12 -0500
> From: Shai Gluskin <shai at content2zero.com
> <mailto:shai at content2zero.com>>
> Subject: Re: [development] Consolidating duplicate contrib modules for
> D7
> To: development at drupal.org <mailto:development at drupal.org>
> Message-ID:
> <9f68efb70911301250mb94a68fj7a4156b4bf3b712f at mail.gmail.com
> <mailto:9f68efb70911301250mb94a68fj7a4156b4bf3b712f at mail.gmail.com>>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I think the important part is giving users good information.
> Asking the docs
> team to write module comparison pieces is a good thing too. But
> I'm against
> any plan that tries to put controls on module creation because the
> freedom
> to scratch an itch has led to great creativity and ingenuity. But
> helping
> module developers know what is already out there, that's always a good
> thing.
>
> When the d.o. re-design launches, I think it is going to be a
> different
> world. And I think it will be a lot clearer where energies should
> be spent
> on helping site builders and other Drupal constitutents get what
> they need.
>
> Shai
> Content2zero Web Development <http://content2zero.com>
>
> On Mon, Nov 30, 2009 at 3:22 PM, Andrew Berry
> <andrewberry at sentex.net <mailto:andrewberry at sentex.net>>wrote:
>
> > On 2009-11-30, at 2:44 PM, Brian Vuyk wrote:
> >
> > > Node Access: http://drupal.org/project/node_access
> > > Nodeaccess: http://drupal.org/project/nodeaccess
> >
> > IMO there should be a CVS policy disallowing namespaces to be
> > differentiated with dashes, underscores, spaces, and so on. This
> is a
> > perfect example of the confusion this can cause.
> >
> > > is it worth starting something along the lines of #D7CX to
> consolidate
> > the dupes in the name of a better user experience?
> >
> > I think that if this is something you want to do, you should try
> and find
> > some of the more popular maintained modules and try to get one
> or two sets
> > of projects on board. Once there are a few big projects starting
> down this
> > path, I think it would really help to encourage the smaller
> projects to work
> > together.
> >
> > --Andrew
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.drupal.org/pipermail/development/attachments/20091130/ca4380e0/attachment-0001.html
>
> ------------------------------
>
> Message: 5
> Date: Mon, 30 Nov 2009 16:08:07 -0800
> From: "David Cohen" <drupal at dave-cohen.com
> <mailto:drupal at dave-cohen.com>>
> Subject: [development] alter theme registry, but only for some
> themes.
> possible?
> To: development at drupal.org <mailto:development at drupal.org>
> Message-ID:
> <1259626087.7546.1347767341 at webmail.messagingengine.com
> <mailto:1259626087.7546.1347767341 at webmail.messagingengine.com>>
> Content-Type: text/plain; charset="us-ascii"
>
> I have some modules that alter the theme registry. In practice, I
> could
> limit these alterations to only some themes. On a site with multiple
> themes, my modules might need to alter only one or two. However, I
> can't figure a way in code to determine which themes might need these
> alterations.
>
> Ideally, I could allow the administrator to select one or more themes
> which will be used. Either by selecting the themes in a form, or
> possibly by adding something to the theme's .info file.
>
> Is such a thing possible. In particular, how can I ensure that the
> theme registry will be rebuilt after the administrator submits my form
> or edits the .info file? Is there a best practice along these lines?
>
> -Dave
>
> P.S. too bad drupal doesn't support post-process functions in theme...
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 1 Dec 2009 11:29:26 +0100
> From: Martin Stadler <martin at siarp.de <mailto:martin at siarp.de>>
> Subject: Re: [development] Consolidating duplicate contrib modules for
> D7
> To: development at drupal.org <mailto:development at drupal.org>
> Message-ID: <E5FF7DDF-E092-46EF-A3A7-0A06B4352FF9 at siarp.de
> <mailto:E5FF7DDF-E092-46EF-A3A7-0A06B4352FF9 at siarp.de>>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> I think the best solution is a comparison of similar modules on the
> module's project page. Some maintainers do that and it saves you so
> much time and trouble. It's easy and non-restrictive and there's
> nothing that's sacrificed.
>
> Martin
>
>
> Am 30.11.2009 um 21:50 schrieb Shai Gluskin:
>
> > I think the important part is giving users good information. Asking
> > the docs team to write module comparison pieces is a good thing too.
> > But I'm against any plan that tries to put controls on module
> > creation because the freedom to scratch an itch has led to great
> > creativity and ingenuity. But helping module developers know what is
> > already out there, that's always a good thing.
> >
> > When the d.o. re-design launches, I think it is going to be a
> > different world. And I think it will be a lot clearer where energies
> > should be spent on helping site builders and other Drupal
> > constitutents get what they need.
> >
> > Shai
> > Content2zero Web Development
> >
> > On Mon, Nov 30, 2009 at 3:22 PM, Andrew Berry
> > <andrewberry at sentex.net <mailto:andrewberry at sentex.net>> wrote:
> > On 2009-11-30, at 2:44 PM, Brian Vuyk wrote:
> >
> > > Node Access: http://drupal.org/project/node_access
> > > Nodeaccess: http://drupal.org/project/nodeaccess
> >
> > IMO there should be a CVS policy disallowing namespaces to be
> > differentiated with dashes, underscores, spaces, and so on. This is
> > a perfect example of the confusion this can cause.
> >
> > > is it worth starting something along the lines of #D7CX to
> > consolidate the dupes in the name of a better user experience?
> >
> > I think that if this is something you want to do, you should try and
> > find some of the more popular maintained modules and try to get one
> > or two sets of projects on board. Once there are a few big projects
> > starting down this path, I think it would really help to encourage
> > the smaller projects to work together.
> >
> > --Andrew
> >
> >
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 1 Dec 2009 12:33:58 +0100
> From: Zoltan Varady <zoltan at farm.co.hu <mailto:zoltan at farm.co.hu>>
> Subject: Re: [development] Consolidating duplicate contrib modules for
> D7
> To: development <development at drupal.org
> <mailto:development at drupal.org>>
> Message-ID:
> <70defad0912010333y66fb4766s2f299b39960a46ad at mail.gmail.com
> <mailto:70defad0912010333y66fb4766s2f299b39960a46ad at mail.gmail.com>>
> Content-Type: text/plain; charset=UTF-8
>
> You do know about the "Similar Module Review" group, right?
>
> http://groups.drupal.org/similar-module-review
>
> They review similar modules.
>
>
> ------------------------------
>
> --
> [ Drupal development list | http://lists.drupal.org/ ]
>
> End of development Digest, Vol 84, Issue 1
> ******************************************
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20091201/fa6ad00c/attachment-0001.html
More information about the development
mailing list