HI,
If a predefined node say a page, a story or any other content needs to be displayed as a result of search or displaying authors created list of stories, etc is there any way of modifying the default node_view. I mean is there any facility like node_view_alter or something so that i can change the way the content is getting displyed through my module ???????????/
Vishnu
Send development mailing list submissions to
development@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@drupal.org
You can reach the person managing the list at
development-owner@drupal.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of development digest..."
Today's Topics:
1. Re: PHP Standards Group (Naheem Zaffar)
2. Re: PHP Standards Group (Daniel F. Kudwien)
3. Re: PHP Standards Group (Cameron Eagans)
4. Re: PHP Standards Group (Jeff Greenberg)
5. Re: PHP Standards Group (David Metzler)
6. Doing hook_update_N() when module is installed (Randy Fay)
7. Re: Doing hook_update_N() when module is installed (Ken Rickard)
----------------------------------------------------------------------
Message: 1
Date: Wed, 11 Nov 2009 18:10:22 +0000
From: Naheem Zaffar <naheemzaffar@gmail.com>
Subject: Re: [development] PHP Standards Group
To: development@drupal.org
Message-ID:
<3adc77210911111010n462becbcs4ac0bd4a18c1d562@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
2009/11/11 Alex Bronstein <alex@craftyspace.com>
> +1 for requiring PHP 5.3 for D8 (that's obviously not a community decision
> yet, just me saying I'd support a GoPHP 5.3 project)
>
-1 as it kind of involves abandoning a majority of the current user base.
Let's see how the 5.2 thing is handled first - the latest RHEL release is
still on 5.1.6 (with maybe patches that may or may not give it enough
functionality). If RHEL 6 does not get a move on, there could be many users
crying foul on the support forums, and this is with
what-I-assume-is-a-special-case ultra extended 2 year development cycle for
Drupal 7 instead of the previous 6 to 9 month cycles.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20091111/a04bcd88/attachment-0001.html
------------------------------
Message: 2
Date: Wed, 11 Nov 2009 20:37:37 +0100
From: "Daniel F. Kudwien" <news@unleashedmind.com>
Subject: Re: [development] PHP Standards Group
To: <development@drupal.org>
Message-ID: <3b2d01ca6306$6ca1d820$0200a8c0@structworks.com>
Content-Type: text/plain; charset="iso-8859-1"
> "we'll be involved in developing such standards and will
> adopt them wherever feasible, but we do not commit to
> following all standards if they are incompatible with
> Drupal's basic architecture."
>
> --Larry Garfield
+1 Yes, that makes sense. I think it is what we (sometimes silently) did
anyway. Some of our standards are self-made (for good reason), but there
are also a couple that were directly derived from example code snippets on
php.net's documentation pages. In some cases, when there was no consistent
standard on php.net, we even asked them for the proper standard and to fix
their docs.
I'm not quite sure how they can ignore an architecture like Drupal. I'm not
sure whether I know of a PHP framework/CMS that is NOT extensible and
doesn't support extensions to be placed in various locations, and therefore
wouldn't support this strict filepath based namespacing.
Thanks for staying involved, Crell!
sun
------------------------------
Message: 3
Date: Wed, 11 Nov 2009 13:57:51 -0700
From: Cameron Eagans <cweagans@gmail.com>
Subject: Re: [development] PHP Standards Group
To: development@drupal.org
Message-ID:
<b83a0f600911111257x725d71abpbddb5f20c4f6460c@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I'm going to go out on a limb and say that any framework that anybody would
really care about is extensible and will support extensions in different
locations. And +1 to the thing about adopting standards wherever feasible.
-----
Cameron Eagans
Owner, Black Storms Studios, LLC
http://www.blackstormsstudios.com
On Wed, Nov 11, 2009 at 12:37 PM, Daniel F. Kudwien
<news@unleashedmind.com>wrote:
> > "we'll be involved in developing such standards and will
> > adopt them wherever feasible, but we do not commit to
> > following all standards if they are incompatible with
> > Drupal's basic architecture."
> >
> > --Larry Garfield
>
> +1 Yes, that makes sense. I think it is what we (sometimes silently) did
> anyway. Some of our standards are self-made (for good reason), but there
> are also a couple that were directly derived from example code snippets on
> php.net's documentation pages. In some cases, when there was no
> consistent
> standard on php.net, we even asked them for the proper standard and to fix
> their docs.
>
> I'm not quite sure how they can ignore an architecture like Drupal. I'm
> not
> sure whether I know of a PHP framework/CMS that is NOT extensible and
> doesn't support extensions to be placed in various locations, and therefore
> wouldn't support this strict filepath based namespacing.
>
> Thanks for staying involved, Crell!
>
> sun
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20091111/8db82c12/attachment-0001.html
------------------------------
Message: 4
Date: Wed, 11 Nov 2009 16:19:03 -0500
From: Jeff Greenberg <jeff@ayendesigns.com>
Subject: Re: [development] PHP Standards Group
To: development@drupal.org
Message-ID: <4AFB2A47.40001@ayendesigns.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
+1 to Larry for the reasons already enumerated.
The only thing I have to add that may be of value, is an observation of
the past. The appearance of a standard that does not appear to (a) be in
the best interests of the product, (b) best interests of the user,
and/or (c) make much sense other than a standard for standard's sake, is
a phenomenon that happens from time to time.
It makes every bit of sense in these cases to tread lightly, and not
employ the standards that fall under (a) and (b), perhaps even (c),
especially if (c) looks like it could cause unwanted limitations ongoing.
The warning is I've seen this done with, for example, HP clinging to
HP-UX when Linux was starting to get loaded on servers, IBM with DB2, QB
with XML, and I could go on for a long time. Granted, some examples are
come down to Open or Proprietary, but the rationale for being one
instead of the other was the same (with the addition of (d) Revenue),
and usually came down to a belief that the standard would probably go
nowhere, and wherever it *did* go would be outweighed by (a) and (b).
The result, though, in many cases was that by the time clients started
griping about the solution not meeting a standard, and by the time it
became a problem for the company's marketing that could not be ignored,
they were way behind the curve in terms of meeting the standard,
sometimes with disastrous results (for the original product and people
who had lived it, at least).
So, my advice is to look at whatever standard emerges with two
corrective lenses, one for near-sightedness, and one for far-, but
definitely not with tunnel vision...not that you would :-)
Jeff
------------------------------
Message: 5
Date: Wed, 11 Nov 2009 18:43:49 -0800
From: David Metzler <metzlerd@metzlerd.com>
Subject: Re: [development] PHP Standards Group
To: development@drupal.org
Message-ID: <8BBFF315-59F2-4283-8917-332850EBF6DB@metzlerd.com>
Content-Type: text/plain; charset="us-ascii"
I agree whole heartedly with you on this.
FYI: The document appears to have been removed. I'd be interested
in reading it if it ever appears again.
Dave
On Nov 11, 2009, at 9:19 AM, larry@garfieldtech.com wrote:
> It seems to cover fewer things than they used to, but the one it
> does cover is the one that is least Drupal-friendly; specifically
> it mandates a direct Java-style mapping from namespace and class
> name to file name. I dislike that and find it fundamentally Drupal-
> incompatible, but we'll see.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20091111/24793df0/attachment-0001.html
------------------------------
Message: 6
Date: Wed, 11 Nov 2009 21:08:31 -0700
From: Randy Fay <randy@randyfay.com>
Subject: [development] Doing hook_update_N() when module is installed
To: development@drupal.org
Message-ID:
<15c957090911112008m7bce90bg56e6733e4291170e@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I'm doing a module for infrastructure which is all about applying
configuration updates, and it does only configuration, nothing else.
I'd like to create hook_update_N() functions, but I'd also like all of them
to be run when the module is installed.
Is there any "correct" way to do this? Many modules implement the
functionality in both hook_install and hook_update_N, and that's fine for
database-only issues, which is what these were built around (like schema
changes). But it doesnt' really make sense for site config changes.
Obviously, I can run the hook functions from hook_install(), in direct or
indirect ways.
Suggestions?
Thanks,
-Randy
--
Randy Fay
Drupal Development, troubleshooting, and debugging
randy@randyfay.com
+1 970.462.7450
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20091111/969d2f57/attachment-0001.html
------------------------------
Message: 7
Date: Thu, 12 Nov 2009 10:35:38 +0100
From: Ken Rickard <agentrickard@gmail.com>
Subject: Re: [development] Doing hook_update_N() when module is
installed
To: development@drupal.org
Message-ID:
<25b45da00911120135i42e99d29h5f7d8ffbbe35493c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
To run an action the first time a module is installed, use
hook_enable() in D5 or D6.
- Ken
On Thu, Nov 12, 2009 at 5:08 AM, Randy Fay <randy@randyfay.com> wrote:
> I'm doing a module for infrastructure which is all about applying
> configuration updates, and it does only configuration, nothing else.
> I'd like to create hook_update_N() functions, but I'd also like all of them
> to be run when the module is installed.
> Is there any "correct" way to do this? ?Many modules implement the
> functionality in both hook_install and hook_update_N, and that's fine for
> database-only issues, which is what these were built around (like schema
> changes). But it doesnt' really make sense for site config changes.
> Obviously, I can run the hook functions from hook_install(), in direct or
> indirect ways.
> Suggestions?
> Thanks,
> -Randy
> --
> Randy Fay
> Drupal Development, troubleshooting, and debugging
> randy@randyfay.com
> +1 ?970.462.7450
>
>
--
Ken Rickard
agentrickard@gmail.com
http://ken.therickards.com
------------------------------
--
[ Drupal development list | http://lists.drupal.org/ ]
End of development Digest, Vol 83, Issue 20
*******************************************