[development] can you alter the way a node is represented
vishnu vardhan
vishnukmit at gmail.com
Thu Nov 12 13:35:47 UTC 2009
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
On Thu, Nov 12, 2009 at 5:30 PM, <development-request at drupal.org> wrote:
> Send development mailing list submissions to
> 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
>
> You can reach the person managing the list at
> 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. 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 at gmail.com>
> Subject: Re: [development] PHP Standards Group
> To: development at drupal.org
> Message-ID:
> <3adc77210911111010n462becbcs4ac0bd4a18c1d562 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 2009/11/11 Alex Bronstein <alex at 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 at unleashedmind.com>
> Subject: Re: [development] PHP Standards Group
> To: <development at drupal.org>
> Message-ID: <3b2d01ca6306$6ca1d820$0200a8c0 at 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 at gmail.com>
> Subject: Re: [development] PHP Standards Group
> To: development at drupal.org
> Message-ID:
> <b83a0f600911111257x725d71abpbddb5f20c4f6460c at 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 at 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 at ayendesigns.com>
> Subject: Re: [development] PHP Standards Group
> To: development at drupal.org
> Message-ID: <4AFB2A47.40001 at 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 at metzlerd.com>
> Subject: Re: [development] PHP Standards Group
> To: development at drupal.org
> Message-ID: <8BBFF315-59F2-4283-8917-332850EBF6DB at 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 at 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 at randyfay.com>
> Subject: [development] Doing hook_update_N() when module is installed
> To: development at drupal.org
> Message-ID:
> <15c957090911112008m7bce90bg56e6733e4291170e at 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 at 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 at gmail.com>
> Subject: Re: [development] Doing hook_update_N() when module is
> installed
> To: development at drupal.org
> Message-ID:
> <25b45da00911120135i42e99d29h5f7d8ffbbe35493c at 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 at 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 at randyfay.com
> > +1 ?970.462.7450
> >
> >
>
>
>
> --
> Ken Rickard
> agentrickard at gmail.com
> http://ken.therickards.com
>
>
> ------------------------------
>
> --
> [ Drupal development list | http://lists.drupal.org/ ]
>
> End of development Digest, Vol 83, Issue 20
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20091112/20bb2c52/attachment-0001.html
More information about the development
mailing list