Menu
▾
▴
Re: [Apc-aa-coders] Sites: Moving from one URL to another
|
From: Mitra <mi...@mi...> - 2003-01-03 00:15:00
|
Hi Honza
I don't like using the one-line .shtml file, since it means that you
have to go in and setup an HTML file, just for this purpose - when
nothing else on the site currently needs HTML editing. I'd also
like to see site_greenpages.php3 moved into the database, for similar
reasons.
I've put together some functions to make site_greenpages.php3, I'll
share them here when they are ready.
I've got logic in site_greenpages.php3 that tests the m=3D variable and
sets the first field of apc_state, (Copied from your examples) it
works fine, the problem is adding the m=3D variable to a URL, when
there is no way to find that URL from within a view. What URL's are
you putting in your code or are you using f_f and f_b (functions I
never use, because they never do what I want! )
I'm not finding the site code to be very generalized, its specific to
how YOU write sites, I've got a fairly typical (for me) site, where
I have a home page with a list of categories (generated by a view)
and these need to call the site module changing the first state
variable to "c" and setting the item number. I can't figure out how
to do this given the current structure of sites, since the View has
no access to the site variables, so it can't generate the URL.
I've started merging the string expanding code, should be ready later
today. Specifically of course I'll fix some of the problems I'm
having, but hopefully it will be easier to maintain than the several
places it exists now (for example, I hadn't spotted the case in
"itemview" so wouldn't have fixed it.)
The one thing that is making it difficult is the strange "remove"
syntax. there is a lot of complex code in some places to handle ONLY
removing strings from the outer edges, and not from substituted code.
I know that there have been questions several time on apc-aa-general,
about why its done this way. Logically if remove is done last, it
makes sense to apply remove to all the returned string. I'm
reluctant to make the code much more complex in order to implement
this behavior which I think is the not-so-good behavior? What do you
think
As you suggest Honza, I'll copy this to apc-aa-general instead, feel
free to move any conversation to apc-aa-general.
- Mitra
At 11:09 PM +0100 2/1/03, Honza Malik wrote:
>On =DAt, 2002-12-31 at 08:36, Mitra wrote:
>> I'm having difficulty figuring out ways to smoothly move between
>> different parts of a site.
>>
>> I can see how in the site/sites/site_greenpages.php3 file I am
>> looking at an existing state string, and then a new state to change
>> to, but for example .....
>>
>> I have one state "h--1-" which is the home page, and this has a
>> list of "Categories" on it, which are generated by a view, each item
>> in the view wants to be a link that would wants to change the state to
>>
>> m=3Ds i=3D_#SITEM_ID s=3Ds
>>
>> which would be a state string of "s12345s1-"
>
>You can set the state variables by URL (as you do), or you can also add
>the logic into site_greenpages.php3 file. I'm not sure what {m} and {s}
>variable means in your case, but if the {m} allways m=3Ds when you switch
>from homepage, you can set create conditoin in site_greenpages.php3,
>where you qury old {apc} state and {s} url parameter and then it sets
>{m} variable.
>
>> I also have to get teh site_id into the URL, since I'm trying to
>> avoid having a one-line HTML file that contains
>> <!#include /apc-aa+/module/site/site.php3?site_id=3D1a2b3c>
>>
>> I can see several choices to code this, none of which are pretty ....
> >
> > <a
> >
>href=3D"/apc-aa+/modules/site/site.php3?apc=3Ds_#SITEM_IDs1-&site_id=3Da1b2=
b3c">_#HEADLINE</a>
> > or
> > <a
> >
>href=3D"/apc-aa+/modules/site/site.php3?apc=3D{state}&m=3Ds&i=3D_#SITEM_ID&=
s=3Ds&site_id=3Da12b3c">_#HEADLINE</a>
>>
>> (I can abbreviate these slightly to
>> <a href=3D"?apc=3Ds_#SITEM_IDs1-&site_id=3Da1b2b3c">_#HEADLINE</a>
>> or
>> <a href=3D"?apc=3D{state}&m=3Ds&i=3D_#SITEM_ID&s=3Ds&site_id=3Da12b3c">_=
#HEADLINE</a>
>
>We use site module with a file containing only one row:
><!#include /apc-aa+/module/site/site.php3?site_id=3D1a2b3c>
>
>This is not so elegant, but I think it is better than to send site_id in
>all urls.
>
>I think quite elegant solution is to add new database field to site
>table, where you spacify the domain for the site. Then we can change the
>site.php3 script, which will look into site table and compares site.php3
>PHP_SELF uri with the new site-table field (when site_id is not supply).
>It is quite easy code addition).
>
>> But these aren't elegant either, and anyway {state} won't work in a
>> View, unless I fix the code in item.php3 to look up variables in the
>> apc_state array as well (a good idea, something I'll do unless
> > someone says its a bad idea!) Although it would be even better if the
>> code had been merged instead of two VERY similar syntaxes being
>> written separately.
>
>Good idea - go ahead.
>
>> There is a hint on this somewhere (I can't find the reference at the
>> moment) where it refers to the apc=3D{state} part being added to URLs
>> generated by apc-aa.
>
>Yes, it apc state variable is automatically added to urls generated by
>alias functions (f_f, f_b, ...).
>
>> It looks to me like this code was written for a particular way of
>> doing something, and not generalized, the trouble is I can't figure
>> out how it was INTENDED to be used.
>
>No, it is generalized. There are at least three sites using the site
>module without any change a and (as I hope) without any problem:
> http://ecn.cz
> http://changenet.sk
> http://apc-aa.sourceforge.net/slices/index.shtml
>
>
> Honza
>
>PS.shouldn't this discussion be placed in apc-aa-general?
>
>>
>> - Mitra
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Apc-aa-coders mailing list
>Apc...@li...
>https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
--
Mitra Technology Consulting - www.mitra.biz - mi...@mi...
02-6684-8096 or 0414-648-0722
Life is a Mystery to be Lived, not a Problem to be Solved
|
