Also, as a side note: Yaron, is there some forum or mailing list for
Semantic Forms?
--Wiredtape
Ben wrote:
I would like to say thank you for adding going through
this as well :)
regarding jimbojw's words:
I would agree it could be nice to have case-diff links be known link
objects, however, though I can't think of an example atm, I'm sure there
are articles with the same name but different cases - and then it
becomes a problem of trying to understand which is the one the user
meant. Places like search, where TitleKey makes a lot of sense, let the
user make a conscious choice by showing him all of the options.
--Wiredtape
Jim Wilson wrote:
> Thanks Yaron for taking on the task of adding this hook :)
>
> One use case could be for integration with something like Brion's
> TitleKey extension, so if the title already exists, but with a
> different capitalization, a known link obj could be generated rather
> than a broken link obj.
>
> Say for example you're using TitleKey with an additional
> ArticleFromTitle hook to automatically resolve case differences
> (perhaps by 301 redirecting), and the article "WiMAX" already exists.
> When someone links to [[wimax]] - it would be nice to be able to show
> that as a known link obj.
>
> -- Jim R. Wilson (jimbojw)
>
> On Wed, Mar 5, 2008 at 11:59 AM, Yaron Koren <yaron57(a)gmail.com> wrote:
>> Oh, wow - 10 parameters for the hook function? Somehow that seems like
>> overkill, though I don't know what exactly could be removed from that list.
>> Would the call to wfRunHooks() be placed before or after the line that sets
>> the actual link ($s)? If it comes afterwards, passing in the variables of
>> $style and $inside might not be necessary, since those are just helper
>> variables that are used to create the link. Maybe it's also better to not
>> have makeBrokenLinkObj() override the values of $text and $trail, and
>> instead use new variables for those, so that the original values could be
>> passed in without problems (and the new variables could similarly be
>> ignored).
>>
>> -Yaron
>>
>>
>> On Wed, Mar 5, 2008 at 12:43 PM, Simetrical
<Simetrical+wikilist(a)gmail.com>
>> wrote:
>>
>>
>>
>> > On Wed, Mar 5, 2008 at 12:33 PM, Yaron Koren <yaron57(a)gmail.com>
wrote:
>> > > Okay, that makes sense - there's probably no reason to allow more
than
>> > one
>> > > hook to override the output. The one downside of this approach that
I
>> > can
>> > > see is that functions that don't override the output might not
get
>> > called at
>> > > all, if they're later in the array than a function that does
override
>> > it. I
>> > > don't think that's a big deal, since I can't imagine some
large amount
>> > of
>> > > custom code called for every broken link, or two extensions
>> > "collaborating"
>> > > on creating a new link. Unless anyone objects, I'll go with your
>> > suggestion.
>> >
>> > Putting it at the bottom with more parameters seems like a better
>> > idea, on second thought. I'd still permit hooks to return false and
>> > alter some $ret variable to totally change things if they wanted, but
>> > exposing the parameters $u, $style, $prefix, the modified $text,
>> > $inside, and $trail (as well as $nt, $query, and the unmodified $text,
>> > for reference) could allow some extensions to coexist peacefully. If
>> > there's a conflict there's a conflict, of course, but we may as
well
>> > try to avoid that a bit more.
>> >
>> > _______________________________________________
>> > Wikitech-l mailing list
>> > Wikitech-l(a)lists.wikimedia.org
>> >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> >
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l(a)lists.wikimedia.org
>>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>