Mailing List Archive: Interchange: users

flypage specialsub patch

Index | Next | Previous | View Threaded

peter at pajamian

Aug 30, 2009, 12:26 AM

Post #1 of 11 (1787 views)
Permalink

flypage specialsub patch

Hi everyone,

Before I commit this patch can anyone who uses the flypage SpecialSub
test it to see if it breaks anything? It works fine for me.

<http://github.com/pajamian/interchange/commit/00a20b210ed8ae9f56f579da8b426508f224246e>

Peter

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

mike at perusion

Aug 30, 2009, 12:40 PM

Post #2 of 11 (1700 views)
Permalink

Re: flypage specialsub patch [In reply to]

Quoting Peter (peter [at] pajamian):
> Hi everyone,
>
> Before I commit this patch can anyone who uses the flypage SpecialSub
> test it to see if it breaks anything? It works fine for me.
>
> <http://github.com/pajamian/interchange/commit/00a20b210ed8ae9f56f579da8b426508f224246e>
>

What is it supposed to do?

--
Mike Heins
Perusion -- Expert Interchange Consulting http://www.perusion.com/
phone +1.765.328.4479 <mike [at] perusion>

The sun, with all those planets revolving around it and dependent on it,
can still ripen a bunch of grapes as if it had nothing else in the
universe to do. -- Galileo

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

mike at perusion

Aug 30, 2009, 12:49 PM

Post #3 of 11 (1708 views)
Permalink

Re: flypage specialsub patch [In reply to]

Quoting Mike Heins (mike [at] perusion):
> Quoting Peter (peter [at] pajamian):
> > Hi everyone,
> >
> > Before I commit this patch can anyone who uses the flypage SpecialSub
> > test it to see if it breaks anything? It works fine for me.
> >
> > <http://github.com/pajamian/interchange/commit/00a20b210ed8ae9f56f579da8b426508f224246e>
> >
>
> What is it supposed to do?

This comes from my preference that you don't talk about a link in
message as if someone has read the link. You can ignore this, as
I have now read it. I still don't like it.

--
Mike Heins
Perusion -- Expert Interchange Consulting http://www.perusion.com/
phone +1.765.328.4479 <mike [at] perusion>

There's nothing sweeter than life nor more precious than time.
-- Barney

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

peter at pajamian

Aug 30, 2009, 6:05 PM

Post #4 of 11 (1696 views)
Permalink

Re: flypage specialsub patch [In reply to]

On 08/30/2009 12:49 PM, Mike Heins wrote:
> Quoting Mike Heins (mike [at] perusion):
>> Quoting Peter (peter [at] pajamian):
>>> Hi everyone,
>>>
>>> Before I commit this patch can anyone who uses the flypage SpecialSub
>>> test it to see if it breaks anything? It works fine for me.
>>>
>>> <http://github.com/pajamian/interchange/commit/00a20b210ed8ae9f56f579da8b426508f224246e>
>>>
>> What is it supposed to do?
>
> This comes from my preference that you don't talk about a link in
> message as if someone has read the link. You can ignore this, as
> I have now read it. I still don't like it.

Fair enough. I'll explain for the benefit of others and to give you
some more background.

I want to use the flypage specialsub to strip out SEO strings in the URL
when checking for the existence of a SKU, for example, a sku of
123456/foo-bar-baz would get stripped to 123456 with a simple regexp as
the foo-bar-baz is just there for SEOs to key on and to make the URLs
more readable. The problem I was having is that if the resulting sku
doesn't exist the flypage specialsub still pretends like it's a valid
sku and goes on to display what is in essence a flypage with no data.
In fact there is currently no way to tell IC to go on with normal page
processing if you're using the flypage specialsub, so IC will no longer
process directory indexes, will not run the missing specialsub and will
not display the missing special page at all if the flypage specialsub is
defined.

I made the fix linked to above and it works well for me, but before I
commit it I wanted to check to see if it breaks anyone else's code who
might be using flypage for a different purpose than I am. I don't think
it will, but I'm just not sure, so I'm asking.

Peter

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

mike at perusion

Aug 31, 2009, 5:56 AM

Post #5 of 11 (1698 views)
Permalink

Re: flypage specialsub patch [In reply to]

Quoting Peter (peter [at] pajamian):
> On 08/30/2009 12:49 PM, Mike Heins wrote:
> > Quoting Mike Heins (mike [at] perusion):
> >> Quoting Peter (peter [at] pajamian):
> >>> Hi everyone,
> >>>
> >>> Before I commit this patch can anyone who uses the flypage SpecialSub
> >>> test it to see if it breaks anything? It works fine for me.
> >>>
> >>> <http://github.com/pajamian/interchange/commit/00a20b210ed8ae9f56f579da8b426508f224246e>
> >>>
> >> What is it supposed to do?
> >
> > This comes from my preference that you don't talk about a link in
> > message as if someone has read the link. You can ignore this, as
> > I have now read it. I still don't like it.
>
> Fair enough. I'll explain for the benefit of others and to give you
> some more background.
>
> I want to use the flypage specialsub to strip out SEO strings in the URL
> when checking for the existence of a SKU, for example, a sku of
> 123456/foo-bar-baz would get stripped to 123456 with a simple regexp as
> the foo-bar-baz is just there for SEOs to key on and to make the URLs
> more readable. The problem I was having is that if the resulting sku
> doesn't exist the flypage specialsub still pretends like it's a valid
> sku and goes on to display what is in essence a flypage with no data.
> In fact there is currently no way to tell IC to go on with normal page
> processing if you're using the flypage specialsub, so IC will no longer
> process directory indexes, will not run the missing specialsub and will
> not display the missing special page at all if the flypage specialsub is
> defined.
>
> I made the fix linked to above and it works well for me, but before I
> commit it I wanted to check to see if it breaks anyone else's code who
> might be using flypage for a different purpose than I am. I don't think
> it will, but I'm just not sure, so I'm asking.
>

Looks like a good fix to me. I can't imagine that it would cause
a problem even for someone currently using the SpecialSub.

--
Mike Heins
Perusion -- Expert Interchange Consulting http://www.perusion.com/
phone +1.765.328.4479 <mike [at] perusion>

If you like what you're gettin', keep doin' what you're doin'. -- Hector

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

jon at endpoint

Aug 31, 2009, 9:09 AM

Post #6 of 11 (1697 views)
Permalink

Re: flypage specialsub patch [In reply to]

On Mon, 31 Aug 2009, Mike Heins wrote:

> Looks like a good fix to me. I can't imagine that it would cause a
> problem even for someone currently using the SpecialSub.

It looks more reasonable to me than the old code, but the behavior doesn't
quite look compatible. Before, $base could be assigned an arbitrary result
hashref and thus could be used for a different kind of on-the-fly product,
but now it seems the product code has to actually exist in a real
database.

I am not using that feature and don't object to the change, but I thought
I'd point out the different behavior.

Jon

--
Jon Jensen
End Point Corporation
http://www.endpoint.com/

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

mike at perusion

Aug 31, 2009, 12:01 PM

Post #7 of 11 (1688 views)
Permalink

Re: flypage specialsub patch [In reply to]

Quoting Jon Jensen (jon [at] endpoint):
> On Mon, 31 Aug 2009, Mike Heins wrote:
>
> > Looks like a good fix to me. I can't imagine that it would cause a
> > problem even for someone currently using the SpecialSub.
>
> It looks more reasonable to me than the old code, but the behavior doesn't
> quite look compatible. Before, $base could be assigned an arbitrary result
> hashref and thus could be used for a different kind of on-the-fly product,
> but now it seems the product code has to actually exist in a real
> database.

Good point.

> I am not using that feature and don't object to the change, but I thought
> I'd point out the different behavior.

Now that I think about it, it was designed to handle OnFly products so the
change doesn't make sense.

--
Mike Heins
Perusion -- Expert Interchange Consulting http://www.perusion.com/
phone +1.765.328.4479 <mike [at] perusion>

Being against torture ought to be sort of a bipartisan thing.
-- Karl Lehenbauer

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

peter at pajamian

Aug 31, 2009, 1:05 PM

Post #8 of 11 (1690 views)
Permalink

Re: flypage specialsub patch [In reply to]

On 08/31/2009 12:01 PM, Mike Heins wrote:
> Quoting Jon Jensen (jon [at] endpoint):
>> On Mon, 31 Aug 2009, Mike Heins wrote:
>>
>>> Looks like a good fix to me. I can't imagine that it would cause a
>>> problem even for someone currently using the SpecialSub.
>> It looks more reasonable to me than the old code, but the behavior doesn't
>> quite look compatible. Before, $base could be assigned an arbitrary result
>> hashref and thus could be used for a different kind of on-the-fly product,
>> but now it seems the product code has to actually exist in a real
>> database.
>
> Good point.
>
>> I am not using that feature and don't object to the change, but I thought
>> I'd point out the different behavior.
>
> Now that I think about it, it was designed to handle OnFly products so the
> change doesn't make sense.

Ok, well that's why I asked. How about we keep the old code if the
return is a hashref, but if it's just a text scalar which contains a sku
then get $base from product_code_exists_ref()? Also just to give an
explicit way to say, "don't display a flypage for this" a return of
undef could result in the flypage being skipped as if the sku doesn't exist?

Peter

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

jon at endpoint

Aug 31, 2009, 1:49 PM

Post #9 of 11 (1693 views)
Permalink

Re: flypage specialsub patch [In reply to]

On Mon, 31 Aug 2009, Peter wrote:

> Ok, well that's why I asked. How about we keep the old code if the
> return is a hashref, but if it's just a text scalar which contains a sku
> then get $base from product_code_exists_ref()? Also just to give an
> explicit way to say, "don't display a flypage for this" a return of
> undef could result in the flypage being skipped as if the sku doesn't
> exist?

That seems reasonable to me.

Jon

--
Jon Jensen
End Point Corporation
http://www.endpoint.com/

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

mike at perusion

Aug 31, 2009, 1:54 PM

Post #10 of 11 (1689 views)
Permalink

Re: flypage specialsub patch [In reply to]

Quoting Peter (peter [at] pajamian):
> On 08/31/2009 12:01 PM, Mike Heins wrote:
> > Quoting Jon Jensen (jon [at] endpoint):
> >> On Mon, 31 Aug 2009, Mike Heins wrote:
> >>
> >>> Looks like a good fix to me. I can't imagine that it would cause a
> >>> problem even for someone currently using the SpecialSub.
> >> It looks more reasonable to me than the old code, but the behavior doesn't
> >> quite look compatible. Before, $base could be assigned an arbitrary result
> >> hashref and thus could be used for a different kind of on-the-fly product,
> >> but now it seems the product code has to actually exist in a real
> >> database.
> >
> > Good point.
> >
> >> I am not using that feature and don't object to the change, but I thought
> >> I'd point out the different behavior.
> >
> > Now that I think about it, it was designed to handle OnFly products so the
> > change doesn't make sense.
>
> Ok, well that's why I asked. How about we keep the old code if the
> return is a hashref, but if it's just a text scalar which contains a sku
> then get $base from product_code_exists_ref()?

I think that works.

> Also just to give an explicit way to say, "don't display a flypage for
> this" a return of undef could result in the flypage being skipped as
> if the sku doesn't exist?

Yes.

--
Mike Heins
Perusion -- Expert Interchange Consulting http://www.perusion.com/
phone +1.765.328.4479 <mike [at] perusion>

The tenor's voice is spoilt by affectation,
And for the bass, the beast can only bellow;
In fact, he had no singing education,
An ignorant, noteless, timeless, tuneless fellow. -- Lord Byron

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

gert at 3edge

Aug 31, 2009, 11:49 PM

Post #11 of 11 (1675 views)
Permalink

Re: flypage specialsub patch [In reply to]

> -----Original Message-----
> From: interchange-users-bounces [at] icdevgroup [mailto:interchange-
> users-bounces [at] icdevgroup] On Behalf Of Peter
> Sent: Monday, August 31, 2009 11:06 PM
> To: interchange-users [at] icdevgroup
> Subject: Re: [ic] flypage specialsub patch
>
> On 08/31/2009 12:01 PM, Mike Heins wrote:
> > Quoting Jon Jensen (jon [at] endpoint):
> >> On Mon, 31 Aug 2009, Mike Heins wrote:
> >>
> >>> Looks like a good fix to me. I can't imagine that it would cause a
> >>> problem even for someone currently using the SpecialSub.
> >> It looks more reasonable to me than the old code, but the behavior
> doesn't
> >> quite look compatible. Before, $base could be assigned an arbitrary
> result
> >> hashref and thus could be used for a different kind of on-the-fly
> product,
> >> but now it seems the product code has to actually exist in a real
> >> database.
> >
> > Good point.
> >
> >> I am not using that feature and don't object to the change, but I
> thought
> >> I'd point out the different behavior.
> >
> > Now that I think about it, it was designed to handle OnFly products
> so the
> > change doesn't make sense.
>
> Ok, well that's why I asked. How about we keep the old code if the
> return is a hashref, but if it's just a text scalar which contains a
> sku
> then get $base from product_code_exists_ref()? Also just to give an
> explicit way to say, "don't display a flypage for this" a return of
> undef could result in the flypage being skipped as if the sku doesn't
> exist?

+1

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads