apc-aa-coders — Discussion only useful to active developers.

[Apc-aa-coders] IDS - maybe a change to make - lets discuss

[Mitra <mi...@mi...>]

Hi

There is a lot of code, and a lot of mistakes, that happen around the 
different representations for  item ids. We have at least four that I 
know of:
Short id: Sequence of Item in database, used in shorter urls 
especially in views
Packed id: 128 bit packed, stored in database
Unpacked id: 32 character, used in urls
Tagged ids: For example where an x is on the front of a packed id to 
indicate bidirectional.

An example of a Sysadmin mistake was where recently I used related 
items window and stored the string, which then broke something using 
it as a related items link. I had to switch to store item ids.

The reason this came up for me, is that I need a way to add a meaning 
to related item links, which is hard with since a multi-value field 
(like a related item) can only contain one piece of data. I was 
thinking of extending the related item window to allow me to redefine 
the buttons.

What I'm thinking is to add a "class itemid" which would refer to an 
item.  This could be initialised with either shortid, packed, 
unpacked or tagged, and then could - via methods - return any of the 
alternatives e.g.

foo = new itemid(123)
#new itemid(1234567890abcdef1234567890abcdef)

and then foo->packed;

I would use lazy evaluation to do the conversion, i.e. only 
generating the flavors needed.

What do you think?

If we like the idea, I would see it programmed in gradually, i.e. I 
define the class, and its methods and then it can be integrated only 
when we are working on some part of the code.

- Mitra

P.S. I'd still like a hint on how to create a new "item" refering to 
an item id, this would be very useful for use of the site module, but 
I can't figure out if this is possible.


-- 
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

Re: [Apc-aa-coders] Changes: site module, edititem,

[Mitra <mi...@mi...>]

Its a good point, I was trying to think of security holes in it.

I think this is a bit of a non-worry for a number of reasons.
1: Most browsers don't send referer URLs any more - really annoying 
when you are trying to track things down.
2: The hacker would have to be on a site you linked to, and react 
within three hours.

I just don't see this as a big security hole.

- Mitra


At 10:05 PM +0100 12/1/03, Honza Malik wrote:
>On Ne, 2003-01-12 at 02:08, Mitra wrote:
>>  The biggest change is that _#EDITITEM should now work in most cases
>>  outside of the admin interface, with the user being prompted for a
>>  userid/password and then returned back to where they came from.
>
>It's nice. Thanks Mitra.
>
>Just one note: It's not secure to add AA_CP_Session to urls outside of
>AA Admin interface (like in FAQ). If there is any link to any other
>webpage (in FAQ), it is possible to get your session id (AA_CP_Session)
>from 'Referer' field. With this id (or url) you are able to access AA
>admin pages without login (for 3 hours, when session id expires).
>
>I would probably prefer to create the link without the session id (with
>f_e) as default (so users have to log in on every item edit) and then
>maybe create optional f_e for those admins, who knows about this problem
>and don't care. At least we have to mention it in the FAQ.
>
>What you think?
>
>    Honza
>
>>  - Mitra
>>
>>
>>
>>  01/12/02 - changed site module to go to prior sibling when deleting
>>  rather than parent
>>  01/12/02 - added default $item=null to new_unalias_recurent to allow
>>  calling from site module without warnings
>>  01/12/02 - fixed adding AA_CP_Session to url in site module AAPage
>>  where it is already there.
>>  01/12/02 - changes to allow _#EDITITEM to be used outside of admin interface
>>  01/12/02 - combined several ways of redirecting to a URL into common
>>  function go_return_or_url
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>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

Re: [Apc-aa-coders] Changes: site module, edititem,

[Honza M. <hon...@ec...>]

On Ne, 2003-01-12 at 02:08, Mitra wrote: 
> The biggest change is that _#EDITITEM should now work in most cases 
> outside of the admin interface, with the user being prompted for a 
> userid/password and then returned back to where they came from.

It's nice. Thanks Mitra.

Just one note: It's not secure to add AA_CP_Session to urls outside of
AA Admin interface (like in FAQ). If there is any link to any other
webpage (in FAQ), it is possible to get your session id (AA_CP_Session)
from 'Referer' field. With this id (or url) you are able to access AA
admin pages without login (for 3 hours, when session id expires).

I would probably prefer to create the link without the session id (with
f_e) as default (so users have to log in on every item edit) and then
maybe create optional f_e for those admins, who knows about this problem
and don't care. At least we have to mention it in the FAQ.

What you think?

   Honza

> - Mitra
> 
> 
> 
> 01/12/02 - changed site module to go to prior sibling when deleting 
> rather than parent
> 01/12/02 - added default $item=null to new_unalias_recurent to allow 
> calling from site module without warnings
> 01/12/02 - fixed adding AA_CP_Session to url in site module AAPage 
> where it is already there.
> 01/12/02 - changes to allow _#EDITITEM to be used outside of admin interface
> 01/12/02 - combined several ways of redirecting to a URL into common 
> function go_return_or_url

[Apc-aa-coders] See FAQ for example

[Mitra <mi...@mi...>]

See http://apc-aa.sourceforge.net/faq for an example - I've added 
"Edit" so items can be edited as soon as an error is spotted.


- Mitra


>The biggest change is that _#EDITITEM should now work in most cases 
>outside of the admin interface, with the user being prompted for a 
>userid/password and then returned back to where they came from.
>
>- Mitra
>
>
>
>01/12/02 - changed site module to go to prior sibling when deleting 
>rather than parent
>01/12/02 - added default $item=null to new_unalias_recurent to allow 
>calling from site module without warnings
>01/12/02 - fixed adding AA_CP_Session to url in site module AAPage 
>where it is already there.
>01/12/02 - changes to allow _#EDITITEM to be used outside of admin interface
>01/12/02 - combined several ways of redirecting to a URL into common 
>function go_return_or_url
-- 
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

[Apc-aa-coders] Changes: site module, edititem,

[Mitra <mi...@mi...>]

The biggest change is that _#EDITITEM should now work in most cases 
outside of the admin interface, with the user being prompted for a 
userid/password and then returned back to where they came from.

- Mitra



01/12/02 - changed site module to go to prior sibling when deleting 
rather than parent
01/12/02 - added default $item=null to new_unalias_recurent to allow 
calling from site module without warnings
01/12/02 - fixed adding AA_CP_Session to url in site module AAPage 
where it is already there.
01/12/02 - changes to allow _#EDITITEM to be used outside of admin interface
01/12/02 - combined several ways of redirecting to a URL into common 
function go_return_or_url
-- 
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

Re: [Apc-aa-coders] PS to Broken new_unalias_recurent() in current CVS

[Mitra <mi...@mi...>]

OK - its fixed,

The code in there relied on the bug that 'headline........'  gets 
expanded, when really it should be '{headline........}'

I've put some code into item.php3, to recognize parameters that are 
fields, and expand directly instead of using the new_unalias_recurent.

This fix is checked into CVS, so please update and it should fix it.

- Mitra


>Marek
>
>Since both Honza and I have been working on code around this area, 
>can you make sure that you update to the latest CVS immediately 
>before reporting the bug, then I (or Honza) will know we are 
>duplicating your bug on the same code.
>
>I *am* working most of this weekend, so I should be able to get to 
>this quickly.
>
>- Mitra
>
>>Marek
>>
>>Its perfectly legitimate to not pass parameters, you'll notice that 
>>parameters 6 and 7 contain defaults.
>>
>>For the other item, do you have
>>
>>1: An alias e.g. _#HEAD_URL  defined using this function
>>OR
>>have it bare in a view - e.g. 
>>{alias:headline........:f_b::/members/country/full.shtml:headline........::class="res_link":}
>>
>>Let me know so that I can duplicate the problem.
>>
>>It would also help if you gave me a URL I could test it on - and/or 
>>ran that URL adding "debug=1" to the result and emailed me the 
>>result.
>>
>>- Mitra
>>
>>
>>
>>At 8:10 PM +0100 10/1/03, Marek Tichy wrote:
>>>Just tried cvs update and afterwards got lots of
>>>
>>>Warning: Missing argument 7 for new_unalias_recurent() in 
>>>/data/www/htdocs/ein.org.uk/aa/include/stringexpand.php3 on line 
>>>210
>>>
>>>Warning: Missing argument 6 for new_unalias_recurent() in 
>>>/data/www/htdocs/ein.org.uk/aa/include/stringexpand.php3 on line 
>>>210
>>>
>>>But that's just a minor issue, which can be fixed
>>>
>>>bash-2.05b$ diff item.php3 item.php3-
>>>409c409
>>><     return new_unalias_recurent($text, $remove, $level, 
>>>$maxlevel, $this,null,null); # Note no itemview param
>>>---
>>>  >     return new_unalias_recurent($text, $remove, $level, 
>>>$maxlevel, $this ); # Note no itemview param
>>>
>>>But new_unalias_recurent is not unaliasing properly, i have things 
>>>like headline..... - when printing link using f_b function with
>>>following params:
>>>
>>>::/members/country/full.shtml:headline........::class="res_link":
>>>
>>>all over the site.
>>>
>>>Any ideas ?
>>>
>>>It's likely that the problem is in new_unalias_recurent function, 
>>>but I'm unable to fix.
>>>
>>>Marek
>>>
>>>  > -----Original Message-----
>>>  > From: apc...@li...
>>>  > [mailto:apc...@li...]On Behalf Of Mitra
>>>  > Sent: 03 January 2003 23:20
>>>  > To: APC AA General
>>>  > Subject: [Apc-aa-coders] Remove string behavior - possible change
>>>  >
>>>  >
>>>  > Is anyone likely  to have problems if the Remove strings apply to the
>>>  > entire result of a view/slice rather than just to certain parts as it
>>>  > does now?
>>>  >
>>>  > Honza - I'm ready to CVS submit the merged string handling code, but
>>>  > just need your ok on doing this because of the change to Remove.
>>>  >
>>>  > - Mitra
>>>  >
>>>  > --
>>>  > 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
>>>  >
>>>  >
>>>  >
>>>  > -------------------------------------------------------
>>>  > 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
>>>  >
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.NET email is sponsored by:
>>>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>>>http://www.vasoftware.com
>>>_______________________________________________
>>>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

[Apc-aa-coders] CVS updates als[xx] & {xx}; f_e;

[Mitra <mi...@mi...>]

I had intended to submit these later, but in the interests of fixing 
Marek's problem I needed to get all versions identical.

I'll do a detailed report on f_e when all the required parts are done 
for this to work.

- Mitra



01/11/02 - Changed typos of _#ITEMEDIT to _#EDITITEM (mitra)
01/11/02 - Changed a type $New_silce to $New_slice in init_page.php3 (mitra)
01/11/02 - Added alias checking so {xx} will also check als[xx] (it
           will default to returning "{xx}" if not set  (mitra)
01/11/02 - Changed f_e to work in views outside of admin (appends
           slice_id instead of session_id if no session id), takes a second
           parameter - return url (not currently specifieable with wizzard),
           and defaults to $PHP_SELF if running with no $sess.  (mitra)

-- 
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

Re: [Apc-aa-coders] PS to Broken new_unalias_recurent() in current CVS

[Mitra <mi...@mi...>]

Marek

Since both Honza and I have been working on code around this area, 
can you make sure that you update to the latest CVS immediately 
before reporting the bug, then I (or Honza) will know we are 
duplicating your bug on the same code.

I *am* working most of this weekend, so I should be able to get to 
this quickly.

- Mitra

>Marek
>
>Its perfectly legitimate to not pass parameters, you'll notice that 
>parameters 6 and 7 contain defaults.
>
>For the other item, do you have
>
>1: An alias e.g. _#HEAD_URL  defined using this function
>OR
>have it bare in a view - e.g. 
>{alias:headline........:f_b::/members/country/full.shtml:headline........::class="res_link":}
>
>Let me know so that I can duplicate the problem.
>
>It would also help if you gave me a URL I could test it on - and/or 
>ran that URL adding "debug=1" to the result and emailed me the 
>result.
>
>- Mitra
>
>
>
>At 8:10 PM +0100 10/1/03, Marek Tichy wrote:
>>Just tried cvs update and afterwards got lots of
>>
>>Warning: Missing argument 7 for new_unalias_recurent() in 
>>/data/www/htdocs/ein.org.uk/aa/include/stringexpand.php3 on line 210
>>
>>Warning: Missing argument 6 for new_unalias_recurent() in 
>>/data/www/htdocs/ein.org.uk/aa/include/stringexpand.php3 on line 210
>>
>>But that's just a minor issue, which can be fixed
>>
>>bash-2.05b$ diff item.php3 item.php3-
>>409c409
>><     return new_unalias_recurent($text, $remove, $level, 
>>$maxlevel, $this,null,null); # Note no itemview param
>>---
>>  >     return new_unalias_recurent($text, $remove, $level, 
>>$maxlevel, $this ); # Note no itemview param
>>
>>But new_unalias_recurent is not unaliasing properly, i have things 
>>like headline..... - when printing link using f_b function with
>>following params:
>>
>>::/members/country/full.shtml:headline........::class="res_link":
>>
>>all over the site.
>>
>>Any ideas ?
>>
>>It's likely that the problem is in new_unalias_recurent function, 
>>but I'm unable to fix.
>>
>>Marek
>>
>>  > -----Original Message-----
>>  > From: apc...@li...
>>  > [mailto:apc...@li...]On Behalf Of Mitra
>>  > Sent: 03 January 2003 23:20
>>  > To: APC AA General
>>  > Subject: [Apc-aa-coders] Remove string behavior - possible change
>>  >
>>  >
>>  > Is anyone likely  to have problems if the Remove strings apply to the
>>  > entire result of a view/slice rather than just to certain parts as it
>>  > does now?
>>  >
>>  > Honza - I'm ready to CVS submit the merged string handling code, but
>>  > just need your ok on doing this because of the change to Remove.
>>  >
>>  > - Mitra
>>  >
>>  > --
>>  > 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
>>  >
>>  >
>>  >
>>  > -------------------------------------------------------
>>  > 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
>>  >
>>
>>
>>
>>-------------------------------------------------------
>>This SF.NET email is sponsored by:
>>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>>http://www.vasoftware.com
>>_______________________________________________
>>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

Re: [Apc-aa-coders] Bug in site editor - not fixed yet.

[Mitra <mi...@mi...>]

The code sending spot_id seemed to work,it wasn't being reset from 
the session variable, because I no longer registered r_spot_id with 
the session, but your way also works.

- Mitra


At 12:45 AM +0100 11/1/03, Honza Malik wrote:
>Hi Mitra,
>
>    I'm the coder of site module so all the the laments let go on my
>head. I'm agree it was not happy decision to have spot_id in session,
>but it is quite easy to fix. I will do it, when I will find a time.
>
>    As I see you tried to fix the problem by sending 'spot id' whenever
>you send data to the server, which is good solution, but probably not
>working if you are sending the r_spot_id variable. r_spot_id variable is
>(like any other r_* variables) session variable, so if you send it by
>GET or POST, it is reset in init_page.php3 from session.
>
>    I fixed the code (to send site_id instead). It is in CVS. I test it
>just for a while, but it looks it works. Please test it, if you can.
>
>    Regards,
>              Honza
>
>
>On =DAt, 2003-01-07 at 01:11, Mitra wrote:
>>  There is definately a nasty bug in the site editor, its doing things
>>  like overwriting the wrong Spot during an edit etc.
>>
>>  I'm suspecting its got something to do with the session variable which
>>  stores the spot id, although I'm not doing any of the obviously bad
>>  things to do when someone is using session variables (like using Back
>>  or Forward).
>>
>>  <FLAME>
>>  What I fail to understand is why whoever coded this (it isn't signed)
>>  used a site variable in the first place, this information could EASILY
>>  have been incorporated into the URL without the inherent bugs of
>>  session variables.
>>
>>  Just to be clear - in case you don't know why session variables are a
>>  BAD idea,
>>  If I do something to change the spot I'm looking at, and then hit
>>  Back, then my browser thinks I'm on one spot, while the server thinks
>>  I'm on another one.
>>
>>  Its fine to use Session Variables to cache stuff like authentication
>>  but NEVER use them for maintaining state that changes between screens,
>>  you'll get caught time and time again because the web was never
>>  designed to work with a one-way flow. (Believe me, I was at the
>  > meetings where this was discussed, and a primary design goal of the
>  > web - unlike the existing database systems around at the time - was to
>  > make it stateless, and therefore able to branch, go back and forth
>>  without talking to the server, and be bookmarkable)
>>
>>  I'd love whoever wrote this code to say something ..... before I go
>>  and poke around in the code, at this point my temptation is to just
>>  rip out the session variable code from this module !
>>
>>  </FLAME>
>>  - Mitra
>>
>>
>>  --
>>  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
>>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com
>_______________________________________________
>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

Re: [Apc-aa-coders] Broken new_unalias_recurent() in current CVS

[Mitra <mi...@mi...>]

Marek

Its perfectly legitimate to not pass parameters, you'll notice that 
parameters 6 and 7 contain defaults.

For the other item, do you have

1: An alias e.g. _#HEAD_URL  defined using this function
OR
have it bare in a view - e.g. 
{alias:headline........:f_b::/members/country/full.shtml:headline........::class="res_link":}

Let me know so that I can duplicate the problem.

It would also help if you gave me a URL I could test it on - and/or 
ran that URL adding "debug=1" to the result and emailed me the result.

- Mitra



At 8:10 PM +0100 10/1/03, Marek Tichy wrote:
>Just tried cvs update and afterwards got lots of
>
>Warning: Missing argument 7 for new_unalias_recurent() in 
>/data/www/htdocs/ein.org.uk/aa/include/stringexpand.php3 on line 210
>
>Warning: Missing argument 6 for new_unalias_recurent() in 
>/data/www/htdocs/ein.org.uk/aa/include/stringexpand.php3 on line 210
>
>But that's just a minor issue, which can be fixed
>
>bash-2.05b$ diff item.php3 item.php3-
>409c409
><     return new_unalias_recurent($text, $remove, $level, $maxlevel, 
>$this,null,null); # Note no itemview param
>---
>>      return new_unalias_recurent($text, $remove, $level, $maxlevel, 
>>$this ); # Note no itemview param
>
>But new_unalias_recurent is not unaliasing properly, i have things 
>like headline..... - when printing link using f_b function with
>following params:
>
>::/members/country/full.shtml:headline........::class="res_link":
>
>all over the site.
>
>Any ideas ?
>
>It's likely that the problem is in new_unalias_recurent function, 
>but I'm unable to fix.
>
>Marek
>
>>  -----Original Message-----
>>  From: apc...@li...
>>  [mailto:apc...@li...]On Behalf Of Mitra
>>  Sent: 03 January 2003 23:20
>>  To: APC AA General
>>  Subject: [Apc-aa-coders] Remove string behavior - possible change
>>
>>
>>  Is anyone likely  to have problems if the Remove strings apply to the
>>  entire result of a view/slice rather than just to certain parts as it
>>  does now?
>>
>>  Honza - I'm ready to CVS submit the merged string handling code, but
>>  just need your ok on doing this because of the change to Remove.
>>
>>  - Mitra
>>
>>  --
>>  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
>>
>>
>>
>>  -------------------------------------------------------
>>  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
>>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>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

Re: [Apc-aa-coders] Broken new_unalias_recurent() in current CVS

[Honza M. <hon...@ec...>]

I didn't know about the second problem so I fixed just the 'missing
argument ...' bug. It is in CVS. Mitra, can you please look in your new
version of new_unalias_recurent() to fix the unaliasing problem?


BTW, my other today changes in AA:

01/10/02 - fixed bug of not displaying UserManagement pages in NN4.7=20
         - fixed bad display of selected related items, when "Two Boxes"
           input type is used (honzam)
         - {influde()} inline construct accepts "http://" includes, now=20
         - fixed bug of bad number of parameters to
           new_unalias_recurent()
         - fixed problem with modification of bad spot when clicked
           "Back" in browser for 'site module' (r_spot_id changed to
           spot_id)
         - forbiden "action" field name renamed to "akce" in 'site
           module' admin
         - added missing "util.php3" include in "Module Settings" page=20
           for 'site module' (modedit.php3)

   Honza


On P=E1, 2003-01-10 at 20:10, Marek Tichy wrote:
> Just tried cvs update and afterwards got lots of
>=20
> Warning: Missing argument 7 for new_unalias_recurent() in /data/www/htd=
ocs/ein.org.uk/aa/include/stringexpand.php3 on line 210
>=20
> Warning: Missing argument 6 for new_unalias_recurent() in /data/www/htd=
ocs/ein.org.uk/aa/include/stringexpand.php3 on line 210
>=20
> But that's just a minor issue, which can be fixed
>=20
> bash-2.05b$ diff item.php3 item.php3-
> 409c409
> <     return new_unalias_recurent($text, $remove, $level, $maxlevel, $t=
his,null,null); # Note no itemview param
> ---
> >     return new_unalias_recurent($text, $remove, $level, $maxlevel, $t=
his ); # Note no itemview param
>=20
> But new_unalias_recurent is not unaliasing properly, i have things like=
 headline..... - when printing link using f_b function with
> following params:
>=20
> ::/members/country/full.shtml:headline........::class=3D"res_link":
>=20
> all over the site.
>=20
> Any ideas ?
>=20
> It's likely that the problem is in new_unalias_recurent function, but I=
'm unable to fix.
>=20
> Marek
>=20
> > -----Original Message-----
> > From: apc...@li...
> > [mailto:apc...@li...]On Behalf Of Mitra
> > Sent: 03 January 2003 23:20
> > To: APC AA General
> > Subject: [Apc-aa-coders] Remove string behavior - possible change
> >
> >
> > Is anyone likely  to have problems if the Remove strings apply to the
> > entire result of a view/slice rather than just to certain parts as it
> > does now?
> >
> > Honza - I'm ready to CVS submit the merged string handling code, but
> > just need your ok on doing this because of the change to Remove.
> >
> > - Mitra
> >
> > --
> > 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
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Apc-aa-coders mailing list
> Apc...@li...
> https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
>=20

Re: [Apc-aa-coders] Bug in site editor - not fixed yet.

[Honza M. <hon...@ec...>]

Hi Mitra,

   I'm the coder of site module so all the the laments let go on my
head. I'm agree it was not happy decision to have spot_id in session,
but it is quite easy to fix. I will do it, when I will find a time.

   As I see you tried to fix the problem by sending 'spot id' whenever
you send data to the server, which is good solution, but probably not
working if you are sending the r_spot_id variable. r_spot_id variable is
(like any other r_* variables) session variable, so if you send it by
GET or POST, it is reset in init_page.php3 from session.

   I fixed the code (to send site_id instead). It is in CVS. I test it
just for a while, but it looks it works. Please test it, if you can.

   Regards,
             Honza


On =DAt, 2003-01-07 at 01:11, Mitra wrote:
> There is definately a nasty bug in the site editor, its doing things
> like overwriting the wrong Spot during an edit etc.
>
> I'm suspecting its got something to do with the session variable which
> stores the spot id, although I'm not doing any of the obviously bad
> things to do when someone is using session variables (like using Back
> or Forward).
>=20
> <FLAME>
> What I fail to understand is why whoever coded this (it isn't signed)
> used a site variable in the first place, this information could EASILY
> have been incorporated into the URL without the inherent bugs of
> session variables.
>=20
> Just to be clear - in case you don't know why session variables are a
> BAD idea,
> If I do something to change the spot I'm looking at, and then hit
> Back, then my browser thinks I'm on one spot, while the server thinks
> I'm on another one.
>=20
> Its fine to use Session Variables to cache stuff like authentication
> but NEVER use them for maintaining state that changes between screens,
> you'll get caught time and time again because the web was never
> designed to work with a one-way flow. (Believe me, I was at the
> meetings where this was discussed, and a primary design goal of the
> web - unlike the existing database systems around at the time - was to
> make it stateless, and therefore able to branch, go back and forth
> without talking to the server, and be bookmarkable)
>=20
> I'd love whoever wrote this code to say something ..... before I go
> and poke around in the code, at this point my temptation is to just
> rip out the session variable code from this module !
>=20
> </FLAME>
> - Mitra
>=20
>=20
> --=20
> Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
> 02-6684-8096  or 0414-648-0722=20
>=20
> Life is a Mystery to be Lived, not a Problem to be Solved
>=20

Re: [Apc-aa-coders] Related item bug: 2-box field type shows IDs

[Honza M. <hon...@ec...>]

Fixed in CVS.

On St, 2003-01-08 at 02:23, John Hall wrote:
> The new 2-box field type for multiple selections on add/edit forms is very 
> sexy.
> 
> Just noticing a little bug when using this field type for *related items*:
> 
> -- When adding an item, item headlines appear in both boxes as expected.
> 
> -- When editing an item that has related items already associated to it, 
> their full item IDs appear in the "selected" (second) box, rather than 
> their headlines.
> 
> Is apc-aa-coders the best place to report this kind of thing?

I think yes. Thanks for the report.

   Honza

> John
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Apc-aa-coders mailing list
> Apc...@li...
> https://lists.sourceforge.net/lists/listinfo/apc-aa-coders
> 

[Apc-aa-coders] Alerts Admin broken in CVS version

[Mitra <mi...@mi...>]

If you are running the latest CVS version, and go to Slice 
Admin->Alerts/Admin you get the error message:

This tableview is not in $tableview_definitions: alerts_admin. Bailing out.

I've run sql_update so its not a database problem, the table 
tableview_definitions doesn't contain this definition, but I think 
that table is defined dynamically, so I haven't figured out how to 
fix this properly.

- Mitra

-- 
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

[Apc-aa-coders] Broken new_unalias_recurent() in current CVS

[Marek T. <ma...@gn...>]

Just tried cvs update and afterwards got lots of

Warning: Missing argument 7 for new_unalias_recurent() in /data/www/htdocs/ein.org.uk/aa/include/stringexpand.php3 on line 210

Warning: Missing argument 6 for new_unalias_recurent() in /data/www/htdocs/ein.org.uk/aa/include/stringexpand.php3 on line 210

But that's just a minor issue, which can be fixed

bash-2.05b$ diff item.php3 item.php3-
409c409
<     return new_unalias_recurent($text, $remove, $level, $maxlevel, $this,null,null); # Note no itemview param
---
>     return new_unalias_recurent($text, $remove, $level, $maxlevel, $this ); # Note no itemview param

But new_unalias_recurent is not unaliasing properly, i have things like headline..... - when printing link using f_b function with
following params:

::/members/country/full.shtml:headline........::class="res_link":

all over the site.

Any ideas ?

It's likely that the problem is in new_unalias_recurent function, but I'm unable to fix.

Marek

> -----Original Message-----
> From: apc...@li...
> [mailto:apc...@li...]On Behalf Of Mitra
> Sent: 03 January 2003 23:20
> To: APC AA General
> Subject: [Apc-aa-coders] Remove string behavior - possible change
>
>
> Is anyone likely  to have problems if the Remove strings apply to the
> entire result of a view/slice rather than just to certain parts as it
> does now?
>
> Honza - I'm ready to CVS submit the merged string handling code, but
> just need your ok on doing this because of the change to Remove.
>
> - Mitra
>
> --
> 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
>
>
>
> -------------------------------------------------------
> 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
>

[Apc-aa-coders] Javascript fixes for Mac IE

[Mitra <mi...@mi...>]

I've fixed a collection of Javacript errors that preventing many 
actions - like deleting RSS feeds - on Mac IE.   And committed it to 
CVS

- Mitra


- fixed javascript bugs preventing for example deletion of RSS feeds 
on Mac IE, two bugs (mitra)
         -- if the index of a selection is -1 (not selected) you can't 
retrieve a value
         -- you can't test against undefined, have to test against null.

-- 
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

[Apc-aa-coders] Related item bug: 2-box field type shows IDs

[John H. <jh...@we...>]

The new 2-box field type for multiple selections on add/edit forms is very 
sexy.

Just noticing a little bug when using this field type for *related items*:

-- When adding an item, item headlines appear in both boxes as expected.

-- When editing an item that has related items already associated to it, 
their full item IDs appear in the "selected" (second) box, rather than 
their headlines.

Is apc-aa-coders the best place to report this kind of thing?

John

[Apc-aa-coders] Bug in site editor - not fixed yet.

[Mitra <mi...@mi...>]

There is definately a nasty bug in the site editor, its doing things 
like overwriting the wrong Spot during an edit etc.

I'm suspecting its got something to do with the session variable 
which stores the spot id, although I'm not doing any of the obviously 
bad things to do when someone is using session variables (like using 
Back or Forward).

<FLAME>

What I fail to understand is why whoever coded this (it isn't signed) 
used a site variable in the first place, this information could 
EASILY have been incorporated into the URL without the inherent bugs 
of session variables.

Just to be clear - in case you don't know why session variables are a BAD idea,
If I do something to change the spot I'm looking at, and then hit 
Back, then my browser thinks I'm on one spot, while the server thinks 
I'm on another one.

Its fine to use Session Variables to cache stuff like authentication 
but NEVER use them for maintaining state that changes between 
screens, you'll get caught time and time again because the web was 
never designed to work with a one-way flow. (Believe me, I was at the 
meetings where this was discussed, and a primary design goal of the 
web - unlike the existing database systems around at the time - was 
to make it stateless, and therefore able to branch, go back and forth 
without talking to the server, and be bookmarkable)

I'd love whoever wrote this code to say something ..... before I go 
and poke around in the code, at this point my temptation is to just 
rip out the session variable code from this module !

</FLAME>

- Mitra


-- 
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

Re: [Apc-aa-coders] Site.php3: nocache and cache invalidation

[Mitra <mi...@mi...>]

No - I havent' seen any problems with the long delays - but I haven't 
looked for the expiry problem, that might be an issue., but none of 
the expiry dates are critical on my sites - they are basically used 
just as a way to reduce clutter, i.e. delete older items.

- Mitra


At 8:50 PM +0100 6/1/03, Honza Malik wrote:
>  > There are two cases we are talking about here.
>>
>>  1: Where a change in a change in any slice used by a site needs to
>>  invalidate the site. This seems to work fine.
>>
>>  2: Where changes to the site structure - e.g. the Spot's and Options
>>  - should change anything cached for that Site - it does NOT need to
>>  change things for the other Slices, since those slices internal views
>>  haven't been changed. For this the change I  made to site/index.php3
>>  is necessary and sufficient, otherwise when editing site parameters
>>  the old output is returned from the cache and is wrong.
>
>Right. For this solution you also have to add the site_id into
>$slices4cache array in site_*.php3 script, I think, but it is OK. Good
>solution.
>
>>  While I don't agree with you that you need to invalidate cache for
>>  other slices in mod_edit.php3, i.e. changes to a site cannot effect
>>  component slices. I have not touched that code.
>>
>  > Also - note that 10 mins is the DEFAULT timeout, but a comment
>>  somewhere says you can set it to much longer BECAUSE of cache
>>  invalidation.  To get around apc-aa being VERY SLOW in some complex
>>  cases we have this set to about 2 days on our installation, which is
>>  why I care about invalidation being done correctly!
>
>Oh, 2 days - It's nice to read it works with so long cache time. Do you
>have any experiences/problems with such settings?
>
>I suppose there could be small problem with 'expiry date' - there could
>be items which is visible 2 days longer, than expected on the public
>website.
>
>    Honza
>
>>  - Mitra
>>
>>
>>
>>
>>  At 10:28 PM +0100 5/1/03, Honza Malik wrote:
>>  >On =DAt, 2002-12-31 at 07:52, Mitra wrote:
>>  >>  I've had some weirdness with old versions of pages being retrieved
>>  >>  from the cache.
>>  >>
>>  >>  One thing i notice is that on line 101 of slice.php3 it tests agains=
t
>  > >>  nocache when doing a store.
>  > >>
>  > >>  If I understand the logic, shouldn't nocache ONLY apply to retrievi=
ng
>  > >>  from the cache.
>  > >>
>  > >>  I.e. when you do a retrieve you set nocache, and it would ignore th=
e
>>  >>  cached value of the page, but would then cache the new, correct, pag=
e?
>>  >
>>  >No, nocache parameter is intended to use really no cache. Nor for get,
>>  >nor for store. I offten use noceche parameter for debuging and there is
>>  >good oportunity to store some debug messages into chache, if we
>>  >implement nocache parameter another way.
>>  >
>>  >If you want, you can implement 'renewcache' parameter or such, which
>>  >will behave as you describe.
>>  >
>>  >>  It looks like the cache isn't being invalidated as the Spot's are
>>  >>  being changed, this appears to be happening in site/index.php3 which
>>  >>  doesn't appear to be doing any cache invalidation.
>>  >>
>>  >>  I'm not sure how to invalidate the cache, since the example I find -
>>  >>  site/modedit.php3:139  seems (if I understand things correctly) to
>>  >>  invalidate the cache for all slices, so I'm guessing I'm
>>  >>  misunderstanding something
>>  >
>>  >That's right - it is not optimal solution, but the only possible. The
>>  >modedit for site in not called so often, so I think we can invalidate
>>  >whole cache time to time.
>>  >
>>  >Explanation - how cache works:
>>  >
>>  >It uses folowing database structure:
>>  >   CREATE TABLE pagecache (
>>  >     id varchar(32) NOT NULL, # md5 crypted keystring used as database
>>  >                              # primary key (for quicker database  
>>  >                              # searching)
>>  >     str2find text NOT NULL,  # string used to find record on manual
>>  >                              # invalidation of cache record
>  > >                              # (- it could be keystring)
>>  >     content mediumtext,      # cached information
>>  >     stored bigint,           # timestamp of information storing
>>  >     flag int,                # flag - not used for now
>>  >   PRIMARY KEY (id), KEY (stored));
>>  >
>>  >Row example:
>>  >   id:       56b6dc163ea533b88227eee94b37bee4
>>  >   str2find: slice_id=3D11783cf03dbb66773c1219bd8b6f7456
>>  >   content:  <table width=3D"600"><tr><td colspan=3D3><br><font s...
>>  >   stored:   1041798783
>>  >   flag:     0
>>  >
>>  >
>>  >Basicaly - if you store something to the cache, you use
>>  >   $cache->store($keystring, $content, $str2find);
>>  >
>>  >where:
>>  >   $keystring is any string wich fully identifies the resulting
>>  >              content (it is all view's parameteres joined into string,
>>  >              for example). There is called md5() on $keystring before =
it
>>  >              is stored into database, so the search for the keystring =
is
>>  >              then much quicker.
>>  >
>>  >   $content   is the content which should be generated for $keystring
>>  >
>>  >   $str2find  is some string, which we can use, if we want to invalidat=
e
>>  >              some specific cache content
>>  >
>>  >So, if we want to store content of view from slice 16166... we set
>>  >$str2find =3D 'slice_id=3D16166...'. Everytime the content of any slice=
 is
>>  >changed (new item added, any item in the slice is changed, moved, ...)
>>  >the function:
>>  >   $cache->invalidateFor($cond)
>>  >is AUTOMATICALY called by AA, where $cond=3D'slice_id=3D16166...' in ou=
r
>>  >case.
>>  >
>>  >The invalidateFor function looks for all cache records wich contains th=
e
>>  >string 'slice_id=3D16166...' in str2find field (so probably holds any
>>  >information from the given slice) and invalidates such records (deletes
>>  >it).
>>  >
>>  >Back to the Mitra's question:
>>  >
>>  >>  Am I correct in assuming that invalidate call in modedit.php3:139 is
>>  >>  buggy, and that I should add the code
>>  >>
>>  >>  $cache =3D new PageCache($db,CACHE_TTL,CACHE_PURGE_FREQ); # 
>>database changed -
>>  >>     $cache->invalidate("slice_id=3D".site_id);  # invalidate old 
>>cached values
>>  >>
>>  >>  into index.php3.
>>  >
>>  >Not at all - it is not enough. Site module uses outputs from many
>>  >slices/viws, but the site itself do not know, which all slices it uses.
>>  >So, if we invalidate cache just for "slice_id=3D".site_id, there probab=
ly
>>  >remain cached some views, which is used in the site. Such views could
>>  >have old values, so if we want to be sure, we have to invalidate whole
>>  >cache.
>>  >
>>  >I have to note, this is ONLY the case of changing parameters in site
>>  >module settings which is called really seldom. In main site.php3 script
>>  >is the invalidation much clever. There we use $slices4cache array which
>>  >lists all slices used in the site:
>>  >
>>  >$slices4cache =3D
>>  >   array( "cee194633366705889fd2f58d428ec05", // Ecn - events'
>>  >          "9e9acc045677619191191256ac7cd2ac", // Ecn - authors'
>>  >          "04280ba6756556a6dd802607a3b0edd9", // Ecn - banners'
>>  >          "8ce38f43331abd2e555c533795313851", // Ecn - prices'
>>  >          "6563656767536f6e6e6563742e2e2e2e", // Ecn - about'
>>  >          ...);
>>  >
>>  >Then we can use str2find string just like:
>>  >
>>  >"slice_id=3Dcee194633366705889fd2f58d428ec05,slice_id=3D9e9acc045677619=
191
>>  >191256ac7cd2ac,slice_id=3D04280ba6756556a6dd802607a3b0edd9,slice_id=3D8=
ce3
>>  >8f43331abd2e555c533795313851,slice_id=3D6563656767536f6e6e6563742e2e2e2=
e"
>>  >
>>  >so any change in any listed slice leads to invalidation of the chache
>>  >for the current site (which uses this slice, of course).
>>  >
>>  >Last note: all values are cached for maximum 10 minutes (see CACHE_TTL
>>  >parameter in config.php3)
>>  >
>>  >    Honza
>>  >
>>  >
>>  >
>>  >>  I've done this - and it appears to work - but I wanted to check I'm
>>  >>  understanding the cache logic correctly before I commit to CVS.
>>  >>
>>  >>  - 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
>>
>
>
>
>-------------------------------------------------------
>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

Re: [Apc-aa-coders] Site.php3: nocache and cache invalidation

[Honza M. <hon...@ec...>]

> There are two cases we are talking about here.
>=20
> 1: Where a change in a change in any slice used by a site needs to=20
> invalidate the site. This seems to work fine.
>=20
> 2: Where changes to the site structure - e.g. the Spot's and Options=20
> - should change anything cached for that Site - it does NOT need to=20
> change things for the other Slices, since those slices internal views=20
> haven't been changed. For this the change I  made to site/index.php3=20
> is necessary and sufficient, otherwise when editing site parameters=20
> the old output is returned from the cache and is wrong.

Right. For this solution you also have to add the site_id into
$slices4cache array in site_*.php3 script, I think, but it is OK. Good
solution.

> While I don't agree with you that you need to invalidate cache for=20
> other slices in mod_edit.php3, i.e. changes to a site cannot effect=20
> component slices. I have not touched that code.
>=20
> Also - note that 10 mins is the DEFAULT timeout, but a comment=20
> somewhere says you can set it to much longer BECAUSE of cache=20
> invalidation.  To get around apc-aa being VERY SLOW in some complex=20
> cases we have this set to about 2 days on our installation, which is=20
> why I care about invalidation being done correctly!

Oh, 2 days - It's nice to read it works with so long cache time. Do you
have any experiences/problems with such settings?

I suppose there could be small problem with 'expiry date' - there could
be items which is visible 2 days longer, than expected on the public
website.

   Honza

> - Mitra
>=20
>=20
>=20
>=20
> At 10:28 PM +0100 5/1/03, Honza Malik wrote:
> >On =DAt, 2002-12-31 at 07:52, Mitra wrote:
> >>  I've had some weirdness with old versions of pages being retrieved
> >>  from the cache.
> >>
> >>  One thing i notice is that on line 101 of slice.php3 it tests again=
st
> >>  nocache when doing a store.
> >>
> >>  If I understand the logic, shouldn't nocache ONLY apply to retrievi=
ng
> >>  from the cache.
> >>
> >>  I.e. when you do a retrieve you set nocache, and it would ignore th=
e
> >>  cached value of the page, but would then cache the new, correct, pa=
ge?
> >
> >No, nocache parameter is intended to use really no cache. Nor for get,
> >nor for store. I offten use noceche parameter for debuging and there i=
s
> >good oportunity to store some debug messages into chache, if we
> >implement nocache parameter another way.
> >
> >If you want, you can implement 'renewcache' parameter or such, which
> >will behave as you describe.
> >
> >>  It looks like the cache isn't being invalidated as the Spot's are
> >>  being changed, this appears to be happening in site/index.php3 whic=
h
> >>  doesn't appear to be doing any cache invalidation.
> >>
> >>  I'm not sure how to invalidate the cache, since the example I find =
-
> >>  site/modedit.php3:139  seems (if I understand things correctly) to
> >>  invalidate the cache for all slices, so I'm guessing I'm
> >>  misunderstanding something
> >
> >That's right - it is not optimal solution, but the only possible. The
> >modedit for site in not called so often, so I think we can invalidate
> >whole cache time to time.
> >
> >Explanation - how cache works:
> >
> >It uses folowing database structure:
> >   CREATE TABLE pagecache (
> >     id varchar(32) NOT NULL, # md5 crypted keystring used as database
> >                              # primary key (for quicker database  =20
> >                              # searching)
> >     str2find text NOT NULL,  # string used to find record on manual
> >                              # invalidation of cache record
> >                              # (- it could be keystring)
> >     content mediumtext,      # cached information
> >     stored bigint,           # timestamp of information storing
> >     flag int,                # flag - not used for now
> >   PRIMARY KEY (id), KEY (stored));
> >
> >Row example:
> >   id:       56b6dc163ea533b88227eee94b37bee4
> >   str2find: slice_id=3D11783cf03dbb66773c1219bd8b6f7456
> >   content:  <table width=3D"600"><tr><td colspan=3D3><br><font s...
> >   stored:   1041798783
> >   flag:     0
> >
> >
> >Basicaly - if you store something to the cache, you use
> >   $cache->store($keystring, $content, $str2find);
> >
> >where:
> >   $keystring is any string wich fully identifies the resulting
> >              content (it is all view's parameteres joined into string=
,
> >              for example). There is called md5() on $keystring before=
 it
> >              is stored into database, so the search for the keystring=
 is
> >              then much quicker.
> >
> >   $content   is the content which should be generated for $keystring
> >
> >   $str2find  is some string, which we can use, if we want to invalida=
te
> >              some specific cache content
> >
> >So, if we want to store content of view from slice 16166... we set
> >$str2find =3D 'slice_id=3D16166...'. Everytime the content of any slic=
e is
> >changed (new item added, any item in the slice is changed, moved, ...)
> >the function:
> >   $cache->invalidateFor($cond)
> >is AUTOMATICALY called by AA, where $cond=3D'slice_id=3D16166...' in o=
ur
> >case.
> >
> >The invalidateFor function looks for all cache records wich contains t=
he
> >string 'slice_id=3D16166...' in str2find field (so probably holds any
> >information from the given slice) and invalidates such records (delete=
s
> >it).
> >
> >Back to the Mitra's question:
> >
> >>  Am I correct in assuming that invalidate call in modedit.php3:139 i=
s
> >>  buggy, and that I should add the code
> >>
> >>  $cache =3D new PageCache($db,CACHE_TTL,CACHE_PURGE_FREQ); # databas=
e changed -
> >>     $cache->invalidate("slice_id=3D".site_id);  # invalidate old cac=
hed values
> >>
> >>  into index.php3.
> >
> >Not at all - it is not enough. Site module uses outputs from many
> >slices/viws, but the site itself do not know, which all slices it uses.
> >So, if we invalidate cache just for "slice_id=3D".site_id, there proba=
bly
> >remain cached some views, which is used in the site. Such views could
> >have old values, so if we want to be sure, we have to invalidate whole
> >cache.
> >
> >I have to note, this is ONLY the case of changing parameters in site
> >module settings which is called really seldom. In main site.php3 scrip=
t
> >is the invalidation much clever. There we use $slices4cache array whic=
h
> >lists all slices used in the site:
> >
> >$slices4cache =3D
> >   array( "cee194633366705889fd2f58d428ec05", // Ecn - events'
> >          "9e9acc045677619191191256ac7cd2ac", // Ecn - authors'
> >          "04280ba6756556a6dd802607a3b0edd9", // Ecn - banners'
> >          "8ce38f43331abd2e555c533795313851", // Ecn - prices'
> >          "6563656767536f6e6e6563742e2e2e2e", // Ecn - about'
> >          ...);
> >
> >Then we can use str2find string just like:
> >
> >"slice_id=3Dcee194633366705889fd2f58d428ec05,slice_id=3D9e9acc04567761=
9191
> >191256ac7cd2ac,slice_id=3D04280ba6756556a6dd802607a3b0edd9,slice_id=3D=
8ce3
> >8f43331abd2e555c533795313851,slice_id=3D6563656767536f6e6e6563742e2e2e=
2e"
> >
> >so any change in any listed slice leads to invalidation of the chache
> >for the current site (which uses this slice, of course).
> >
> >Last note: all values are cached for maximum 10 minutes (see CACHE_TTL
> >parameter in config.php3)
> >
> >    Honza
> >
> >
> >
> >>  I've done this - and it appears to work - but I wanted to check I'm
> >>  understanding the cache logic correctly before I commit to CVS.
> >>
> >>  - 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
>=20

[Apc-aa-coders] Bug in site editor - not fixed

[Mitra <mi...@mi...>]

There is some kind of bug in the site editor,

The commands done to the left hand "tree" of spots and choices often 
seem to happen twice, either on the same choice - e.g. move up often 
goes up multiple positions (and yes I don't mean when its skipping 
over choices).

Delete often deletes two choices or spots, possibly this is happenign 
when the next command - e.g. an edit of the spot's content is done.

I have not fixed this ....

- Mitra

-- 
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

Re: [Apc-aa-coders] Site.php3: nocache and cache invalidation

[Mitra <mi...@mi...>]

Hi Honza

There are two cases we are talking about here.

1: Where a change in a change in any slice used by a site needs to 
invalidate the site. This seems to work fine.

2: Where changes to the site structure - e.g. the Spot's and Options 
- should change anything cached for that Site - it does NOT need to 
change things for the other Slices, since those slices internal views 
haven't been changed. For this the change I  made to site/index.php3 
is necessary and sufficient, otherwise when editing site parameters 
the old output is returned from the cache and is wrong.

While I don't agree with you that you need to invalidate cache for 
other slices in mod_edit.php3, i.e. changes to a site cannot effect 
component slices. I have not touched that code.

Also - note that 10 mins is the DEFAULT timeout, but a comment 
somewhere says you can set it to much longer BECAUSE of cache 
invalidation.  To get around apc-aa being VERY SLOW in some complex 
cases we have this set to about 2 days on our installation, which is 
why I care about invalidation being done correctly!

- Mitra




At 10:28 PM +0100 5/1/03, Honza Malik wrote:
>On =DAt, 2002-12-31 at 07:52, Mitra wrote:
>>  I've had some weirdness with old versions of pages being retrieved
>>  from the cache.
>>
>>  One thing i notice is that on line 101 of slice.php3 it tests against
>>  nocache when doing a store.
>>
>>  If I understand the logic, shouldn't nocache ONLY apply to retrieving
>>  from the cache.
>>
>>  I.e. when you do a retrieve you set nocache, and it would ignore the
>>  cached value of the page, but would then cache the new, correct, page?
>
>No, nocache parameter is intended to use really no cache. Nor for get,
>nor for store. I offten use noceche parameter for debuging and there is
>good oportunity to store some debug messages into chache, if we
>implement nocache parameter another way.
>
>If you want, you can implement 'renewcache' parameter or such, which
>will behave as you describe.
>
>>  It looks like the cache isn't being invalidated as the Spot's are
>>  being changed, this appears to be happening in site/index.php3 which
>>  doesn't appear to be doing any cache invalidation.
>>
>>  I'm not sure how to invalidate the cache, since the example I find -
>>  site/modedit.php3:139  seems (if I understand things correctly) to
>>  invalidate the cache for all slices, so I'm guessing I'm
>>  misunderstanding something
>
>That's right - it is not optimal solution, but the only possible. The
>modedit for site in not called so often, so I think we can invalidate
>whole cache time to time.
>
>Explanation - how cache works:
>
>It uses folowing database structure:
>   CREATE TABLE pagecache (
>     id varchar(32) NOT NULL, # md5 crypted keystring used as database
>                              # primary key (for quicker database   
>                              # searching)
>     str2find text NOT NULL,  # string used to find record on manual
>                              # invalidation of cache record
>                              # (- it could be keystring)
>     content mediumtext,      # cached information
>     stored bigint,           # timestamp of information storing
>     flag int,                # flag - not used for now
>   PRIMARY KEY (id), KEY (stored));
>
>Row example:
>   id:       56b6dc163ea533b88227eee94b37bee4
>   str2find: slice_id=3D11783cf03dbb66773c1219bd8b6f7456
>   content:  <table width=3D"600"><tr><td colspan=3D3><br><font s...
>   stored:   1041798783
>   flag:     0
>
>
>Basicaly - if you store something to the cache, you use
>   $cache->store($keystring, $content, $str2find);
>
>where:
>   $keystring is any string wich fully identifies the resulting
>              content (it is all view's parameteres joined into string,
>              for example). There is called md5() on $keystring before it
>              is stored into database, so the search for the keystring is
>              then much quicker.
>
>   $content   is the content which should be generated for $keystring
>
>   $str2find  is some string, which we can use, if we want to invalidate
>              some specific cache content
>
>So, if we want to store content of view from slice 16166... we set
>$str2find =3D 'slice_id=3D16166...'. Everytime the content of any slice is
>changed (new item added, any item in the slice is changed, moved, ...)
>the function:
>   $cache->invalidateFor($cond)
>is AUTOMATICALY called by AA, where $cond=3D'slice_id=3D16166...' in our
>case.
>
>The invalidateFor function looks for all cache records wich contains the
>string 'slice_id=3D16166...' in str2find field (so probably holds any
>information from the given slice) and invalidates such records (deletes
>it).
>
>Back to the Mitra's question:
>
>>  Am I correct in assuming that invalidate call in modedit.php3:139 is
>>  buggy, and that I should add the code
>>
>>  $cache =3D new PageCache($db,CACHE_TTL,CACHE_PURGE_FREQ); # database=
 changed -
>>     $cache->invalidate("slice_id=3D".site_id);  # invalidate old cached v=
alues
>>
>>  into index.php3.
>
>Not at all - it is not enough. Site module uses outputs from many
>slices/viws, but the site itself do not know, which all slices it uses.
>So, if we invalidate cache just for "slice_id=3D".site_id, there probably
>remain cached some views, which is used in the site. Such views could
>have old values, so if we want to be sure, we have to invalidate whole
>cache.
>
>I have to note, this is ONLY the case of changing parameters in site
>module settings which is called really seldom. In main site.php3 script
>is the invalidation much clever. There we use $slices4cache array which
>lists all slices used in the site:
>
>$slices4cache =3D
>   array( "cee194633366705889fd2f58d428ec05", // Ecn - events'
>          "9e9acc045677619191191256ac7cd2ac", // Ecn - authors'
>          "04280ba6756556a6dd802607a3b0edd9", // Ecn - banners'
>          "8ce38f43331abd2e555c533795313851", // Ecn - prices'
>          "6563656767536f6e6e6563742e2e2e2e", // Ecn - about'
>          ...);
>
>Then we can use str2find string just like:
>
>"slice_id=3Dcee194633366705889fd2f58d428ec05,slice_id=3D9e9acc045677619191
>191256ac7cd2ac,slice_id=3D04280ba6756556a6dd802607a3b0edd9,slice_id=3D8ce3
>8f43331abd2e555c533795313851,slice_id=3D6563656767536f6e6e6563742e2e2e2e"
>
>so any change in any listed slice leads to invalidation of the chache
>for the current site (which uses this slice, of course).
>
>Last note: all values are cached for maximum 10 minutes (see CACHE_TTL
>parameter in config.php3)
>
>    Honza
>
>
>
>>  I've done this - and it appears to work - but I wanted to check I'm
>>  understanding the cache logic correctly before I commit to CVS.
>>
>>  - 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

[Apc-aa-coders] Bug - can't use "action" as field of a form (fixed and committed to CVS)

[Mitra <mi...@mi...>]

Action is a form property, and you shouldn't use it as the name of 
one of the fields,

This caused a bug with the omniweb browser where the Javascript that 
set this field to for example "trash" failed.

So .... I've changed all the cases I could find from "action" to 
"akce" (Czech for Action) this means ....the item Manager form - 
which includes changes to admin/feed_to.php3  admin/index.php3  and 
the Related Items form - admin/related_sel.php3

Because the word "action" appears throughout the source its hard to 
be 100% certain I caught all the cases (I almost missed the one in 
feed_to.php3).

- Mitra


-- 
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

Re: [Apc-aa-coders] Site.php3: nocache and cache invalidation

[Honza M. <hon...@ec...>]

On =DAt, 2002-12-31 at 07:52, Mitra wrote:
> I've had some weirdness with old versions of pages being retrieved=20
> from the cache.
>=20
> One thing i notice is that on line 101 of slice.php3 it tests against=20
> nocache when doing a store.
>=20
> If I understand the logic, shouldn't nocache ONLY apply to retrieving=20
> from the cache.
>=20
> I.e. when you do a retrieve you set nocache, and it would ignore the=20
> cached value of the page, but would then cache the new, correct, page?

No, nocache parameter is intended to use really no cache. Nor for get,
nor for store. I offten use noceche parameter for debuging and there is
good oportunity to store some debug messages into chache, if we
implement nocache parameter another way.

If you want, you can implement 'renewcache' parameter or such, which
will behave as you describe.

> It looks like the cache isn't being invalidated as the Spot's are=20
> being changed, this appears to be happening in site/index.php3 which=20
> doesn't appear to be doing any cache invalidation.
>=20
> I'm not sure how to invalidate the cache, since the example I find -=20
> site/modedit.php3:139  seems (if I understand things correctly) to=20
> invalidate the cache for all slices, so I'm guessing I'm=20
> misunderstanding something

That's right - it is not optimal solution, but the only possible. The
modedit for site in not called so often, so I think we can invalidate
whole cache time to time.

Explanation - how cache works:

It uses folowing database structure:
  CREATE TABLE pagecache (
    id varchar(32) NOT NULL, # md5 crypted keystring used as database
                             # primary key (for quicker database   =20
                             # searching)
    str2find text NOT NULL,  # string used to find record on manual
                             # invalidation of cache record
                             # (- it could be keystring)
    content mediumtext,      # cached information
    stored bigint,           # timestamp of information storing
    flag int,                # flag - not used for now
  PRIMARY KEY (id), KEY (stored));

Row example:
  id:       56b6dc163ea533b88227eee94b37bee4=20
  str2find: slice_id=3D11783cf03dbb66773c1219bd8b6f7456=20
  content:  <table width=3D"600"><tr><td colspan=3D3><br><font s...
  stored:   1041798783
  flag:     0


Basicaly - if you store something to the cache, you use=20
  $cache->store($keystring, $content, $str2find);

where:
  $keystring is any string wich fully identifies the resulting
             content (it is all view's parameteres joined into string,
             for example). There is called md5() on $keystring before it
             is stored into database, so the search for the keystring is
             then much quicker.

  $content   is the content which should be generated for $keystring

  $str2find  is some string, which we can use, if we want to invalidate
             some specific cache content

So, if we want to store content of view from slice 16166... we set
$str2find =3D 'slice_id=3D16166...'. Everytime the content of any slice i=
s
changed (new item added, any item in the slice is changed, moved, ...)
the function:
  $cache->invalidateFor($cond)=20
is AUTOMATICALY called by AA, where $cond=3D'slice_id=3D16166...' in our
case.

The invalidateFor function looks for all cache records wich contains the
string 'slice_id=3D16166...' in str2find field (so probably holds any
information from the given slice) and invalidates such records (deletes
it).

Back to the Mitra's question:

> Am I correct in assuming that invalidate call in modedit.php3:139 is=20
> buggy, and that I should add the code
>=20
> $cache =3D new PageCache($db,CACHE_TTL,CACHE_PURGE_FREQ); # database ch=
anged -
>    $cache->invalidate("slice_id=3D".site_id);  # invalidate old cached =
values
>=20
> into index.php3.

Not at all - it is not enough. Site module uses outputs from many
slices/viws, but the site itself do not know, which all slices it uses.
So, if we invalidate cache just for "slice_id=3D".site_id, there probably
remain cached some views, which is used in the site. Such views could
have old values, so if we want to be sure, we have to invalidate whole
cache.

I have to note, this is ONLY the case of changing parameters in site
module settings which is called really seldom. In main site.php3 script
is the invalidation much clever. There we use $slices4cache array which
lists all slices used in the site:

$slices4cache =3D=20
  array( "cee194633366705889fd2f58d428ec05", // Ecn - events'
         "9e9acc045677619191191256ac7cd2ac", // Ecn - authors'
         "04280ba6756556a6dd802607a3b0edd9", // Ecn - banners'
         "8ce38f43331abd2e555c533795313851", // Ecn - prices'
         "6563656767536f6e6e6563742e2e2e2e", // Ecn - about'
         ...);

Then we can use str2find string just like:

"slice_id=3Dcee194633366705889fd2f58d428ec05,slice_id=3D9e9acc04567761919=
1
191256ac7cd2ac,slice_id=3D04280ba6756556a6dd802607a3b0edd9,slice_id=3D8ce=
3
8f43331abd2e555c533795313851,slice_id=3D6563656767536f6e6e6563742e2e2e2e"

so any change in any listed slice leads to invalidation of the chache
for the current site (which uses this slice, of course).

Last note: all values are cached for maximum 10 minutes (see CACHE_TTL
parameter in config.php3)

   Honza



> I've done this - and it appears to work - but I wanted to check I'm=20
> understanding the cache logic correctly before I commit to CVS.
>=20
> - Mitra
>=20
>=20

Re: [Apc-aa-coders] Named views

[Mitra <mi...@mi...>]

I agree, its pretty easy to get a unique name if you want to - you 
could name a view after a slice - for example I would name my views 
for Green Pages, "GreenPages Home" etc. If I need something that is 
almost guarranteed unique then I pick a random number.   But in 
practice I think the hassles from name clashes would be far smaller 
than the ones we have now with import/export.

- Mitra


At 8:54 PM +0100 5/1/03, Honza Malik wrote:
>Hi Mitra, Setu
>
>   I must say I like the acsii names a bit more than the Setus' numbers.
>I think the names solves more than numbers - if you want to create a
>view on your home box and then import new view to the live AA
>installation, then in number version could be problem of already
>existing view. In nemed version (with clever name) is the chance to have
>the same name twice a bit smaller.
>
>    Honza
>
>
>
>On Ne, 2003-01-05 at 20:20, Setu, Prem wrote:
>>  Hi Mitra
>>
>>  The simple ascii name has little problem to keep the view names
>>  unique.
>>  Also it makes importing view difficult, it asks the imported view's
>>  name to be unique in the system width.
>>  If the AA installation has many slices, it can bring confusion.
>>
>>  But yes, it does not need the local ID as number.
>>  If system searches "view name" like follows, it would be better;
>>       1. LOCAL: Searching "view name" in the current slice (if there is
>>          a slice working on).
>>       2. GLOBAL: Searching "view name" in the whole system, 1st one
>>          found will be used.
>>  Also if we can write "view name" with slice identification, it can
>>  avoid mis identification of view.
>>  "view name"+"slice id" or
>>  "view name"+"slice name"
>>
>>  love
>>  setu
>>
>>
>>  Mitra wrote:
>>  > Hi Setu
>>  >
>>  > This seems more complex than needed, what problems would this solve,
>>  > that a simple ascii name would not?
>>  >
>>  > - Mitra
>>  >
>>  >
>>  > At 12:19 PM +0530 5/1/03, Setu, Prem wrote:
>>  > > Hi Mitra
>>  > >
>>  > > I am carrying little ideas for this issue.
>>  > > I am not working for it, just carrying ideas.
>>  > >
>>  > > Bringing two ways to identify the view.
>>  > >         1.     "system global view id" (like now)
>>  > >               * this id will be changed if system is different.
>>  > >               * example
>>  > >                       * 23
>>  > >         2.     "slice local view id". (NEW)
>  > > >               * slice id may different in other system, but local
>  > > >                 view id can be same.
>  > > >               * pair of "slice id" and "local view id"
>>  > >                       * example:
>>  > >                       * _2_8a98eb50efc5d240bc8d6b67f523d40a
>>  > >                               * this is "local view id": 2 in the
>>  > >                                 slice
>>  > >                                 8a98eb50efc5d240bc8d6b67f523d40a
>>  > >               * if the slice id is clear in the context, only
>>  > >                 "local view id" should work.
>>  > >                       * example:
>>  > >                       * _2
>>  > >                               * 2nd view in the slice
>>  > >         3.      It should NOT change the "local view id" when some
>>  > >         views are deleted.
>>  > > this can save our life in two ways...
>>  > >         1.      It makes "shtml files" or "definitions in AA"
>>  > >         portable.
>>  > >         2.      It helps for the implemention work for
>>  > >         "import/export slice with views"
>>  > >               * when import it generate different "system global
>>  > >                 view id", but it keeps "slice local view id" as
>>  > >                 same number.
>>  > > example for view.php3:
>>  > >       * view.php3?vid=3D23        // like now
>>  > >       * view.php3?vid=3D_3_8a98eb50efc5d240bc8d6b67f523d40a    //
>>  > >         new with local view id + slice id
>>  > >               * if it is in shtml file, you can use variable to
>>  > >                 hide slice id:
>>  > >               * view.php3?vid=3D_3_$myslice
>>  > >               * $myslice is defined in installation unique shtml
>  > > >                 file for the portability for other shtml files.
>>  > >       * 
>>view.php3?vid=3D_3_8a98eb50efc5d240bc8d6b67f523d40a&cmd[_3]=3Dx-_3-_#SITEM=
_ID
>>  > >               * for cmd[...]..., slice id is clear, so it works
>>  > >                 only with "local view id".
>>  > >               * or with variable in shtml;
>>  > >                       * view.php3?vid=3D_3_$myslice
>>  > >                       * and "cmd[_3]=3Dx-_3-_#SITEM_ID" will be feed
>>  > >                         through HTML definition of the views.
>>  > > example for slice.php3 with iview=3D or fview=3D
>>  > >       * 
>>slice.php3?slice_id=3D8a98eb50efc5d240bc8d6b67f523d40a&iview=3D_3&fview=3D=
_5
>>  > >               * for iview and fview, slice id is clearly
>>  > >                 identified.
>>  > >               * if it is in shtml file, you can use variable for
>>  > >                 slice id.
>>  > >                       * slice.php3?slice_id=3D$myslice&iview=3D_3&fv=
iew=3D_5
>>  > >                       *
>>  > > example for the parameter of f_v alias function;
>>  > >       * vid=3D_4
>>  > >               * if there is no slice id, same slice which is
>>  > >                 active.
>>  > >       * vid=3D_4_8a98eb50efc5d240bc8d6b67f523d40
>>  > >               * calling view of different slice
>>  > >       * vid=3D_4&cmd[_4]=3Dx-_4-_#SITEM_ID
>>  > >
>>  > > __________________________________________________________________
>>  > > This is another thing, but I thought about using "name".
>>  > >
>>  > > vid=3D(view name)    // global vid by name
>>  > > vid=3D_(view name)  // local vid
>>  > > vid=3D_(view name)_(slice name)   // identify slice by name
>>  > > slice_id=3D(slice name)
>>  > >
>>  > > vid=3D_2_(slice name)
>>  > >
>>  > > If the "name" is not unique, first one found by system is used.
>>  > >
>>  > >
>>  > >
>>  > > Thanks for reading.
>>  > >
>>  > > love
>>  > > setu
>>  > >
>>  > > Mitra wrote:
>>  > > > So ....
>>  > > >
>>  > > > the questions remain - how far did you get, would this be a good
>>  > > > tool to extend to handle more general tasks, for which it needs
>>  > > > to at least export Views, and is there an import version?
>>  > > >
>>  > > > - Mitra
>>  > > >
>>  > > >
>>  > > > At 3:15 PM -0800 28/12/02, Michael de Beer wrote:
>>  > > > > On Sat, 28 Dec 2002 20:55:39 +1100 (EST), "Mitra"
>>  > > > > <mi...@mi...> said:
>>  > > > > >  Mike
>>  > > > > >
>>  > > > > >  Say a little more about your utility
>>  > > > > >
>>  > > > > >  - is there an import equivalent ?
>>  > > > > >  - does it export/import views?
>>  > > > > Yes, there is an import equivalent.  No, it does not
>>  > > > > import/export views.
>>  > > > > >  Basically, what I'm looking for is some way to develop on
>>  > > > > > one box, and
>>  > > > > >  then install on another, a
>>  > > > > >  typical site includes a number of slices, views and
>>  > > > > > constant definitions,
>>  > > > > >  that really want to be
>>  > > > > >  moved as a set?  Developing on a long, sometimes slow, link
>>  > > > > > to a live
>>  > > > > >  server is not really that
>>  > > > > >  productive!
>>  > > > > Agreed.  I have had the same problem.  I used this utility
>>  > > > > when I was
>>  > > > > making a site that had a LOT of fields that needed
>>  > > > > configuring.
>>  > > > > I developed it on my laptop and then exported it to the apc
>>  > > > > website.
>>  > > > > Michael
>>  > > > > >  >
>>  > > > > >  >    Honza
>>  > > > > >  >
>>  > > > > >  > On P=E1, 2002-12-27 at 19:12, Michael de Beer wrote:
>>  > > > > >  >> On Fri, 27 Dec 2002 15:31:17 +0100, "Jakub Adamek"
>>  > > > > >  >> <jak...@se...> said:
>>  > > > > >  >> > There is a simpler way: Generate vid by random. The
>>  > > > > > function must proove the vid generated
>>  > > > > >  >> does not yet exist and if it does than generate another
>>  > > > > > one.
>>  > > > > >  >> > It is not 100% perfect, because there is a chance
>>  > > > > > another installation generated the same
>>  > > > > >  >> id, but it is very simple. And who can be sure the name
>>  > > > > > is unique?
>>  > > > > >  >>
>>  > > > > >  >> I like Mitra's idea of Named views better than
>>  > > > > >  >> Jakub's idea of random ids.  I like 'Names' better
>>  > > > > > because they are human readable.
>>  > > > > >  >>
>  > > > > > >  >> I wrote a script misc/txt2fields/ which is a sort of
>>  > > > > > slice
>>  > > > > >  >> structure export utility that is more human
>>  > > > > > readable/human editable.   I think human-editable
>>  > > > > >  >> is quite useful.
>>  > > > > >  >>
>>  > > > > >  >> However, there is the problem of "Will the Name 'News'
>>  > > > > > be unique?"
>>  > > > > >  >>
>>  > > > > >  >> Would my idea below work -- when a view is created, you
>>  > > > > > can try to give it a 'name'?
>>  > > > > >  >>
>>  > > > > >  >> If a view with that name already exists
>>  > > > > >  >>   AND you have permission to overwrite the view,
>>  > > > >  > >> Then you are asked if you want to overwrite the named
>>  > > > > view with your view.
>>  > > > >  > >>
>>  > > > >  > >> If a view with that name does NOT already exist,
>>  > > > >  > >>   then you are allowed to give it that name.
>>  > > > >  > >>
>>  > > > > >  >> In import utilities there could be a flag that either
>>  > > > > > allows or warns and denies
>>  > > > > >  >> overwrites of views.
>>  > > > > >  >>
>>  > > > > >  >> Michael
>>  > > > > >  >>
>>  > > > > >  >> >
>>  > > > > >  >> > Jakub
>>  > > > > >  >> >
>>  > > > > >  >> > > -----Original Message-----
>>  > > > > >  >> > > From: apc...@li...
>>  > > > > >  >> > > [mailto:apc...@li...]
>>  > > > > > On Behalf Of Mitra Sent: Thursday,
>>  > > > > >  >> December 26, 2002 2:51 AM
>>  > > > > >  >> > > To: apc...@so...
>>  > > > > >  >> > > Subject: [Apc-aa-coders] Named views
>>  > > > > >  >> > >
>>  > > > > >  >> > >
>>  > > > > >  >> > > Has anyone considered adding NAMES to views, so that
>>  > > > > > a vid could be  either a name or a
>>  > > > > >  >> number?
>>  > > > > >  >> > >
>>  > > > > >  >> > > The reason I want to do this is that I'd like to
>>  > > > > > develop a site on my  laptop  macintosh
>>  > > > > >  >> (which has working apc-aa on it) , the problem is  that
>>  > > > > > if I export site structure it will
>>  > > > > >  >> have view numbers - which  will not be usable on the
>>  > > > > > other machine.
>>  > > > > >  >> > >
>>  > > > > >  >> > > If noone has done this - and you think its a good
>>  > > > > > idea - then I might  be willing to make
>>  > > > > >  >> the changes. (by adding an optional name field to
>>  > > > > > views, and having everywhere that vid=3D
>>  > > > > >  >> is recognized understand it? )
>>  > > > > >  >> > >
>>  > > > > >  >> > > - Mitra
>>  > > > > >  >> > >
>>  > > > > >  >> > > --
>>  > > > > >  >> > > 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
>>  > > > > >  >> > >
>>  > > > > >  >> > >
>>  > > > > >  >> > >
>>  > > > > >  >> > >
>>  > > > > > -------------------------------------------------------
>>  > > > > >  >> > > 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
>>  > > > > >  >> > >
>>  > > > > >  >> >
>>  > > > > >  >> >
>>  > > > > >  >> >
>>  > > > > >  >> >
>>  > > > > > -------------------------------------------------------
>>  > > > > >  >> > 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
>>  > > > > >  >> >
>>  > > > > >  >>
>>  > > > > >  >> Michael de Beer
>>  > > > > >  >> mi...@de...
>>  > > > > >  >>
>>  > > > > >  >>
>>  > > > > >  >> -------------------------------------------------------
>>  > > > > >  >> 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
>>  > > > > >  >>
>>  > > > > >  >
>>  > > > > >  >
>>  > > > > >  >
>>  > > > > >  > -------------------------------------------------------
>>  > > > > >  > 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 Internet Consulting
>>  > > > > >  Australia: +61-2-6684-8096; Mobile: +61-414-648-722;  Fax:
>>  > > > > >  +61-7-3319-6130  US: +1-415-704-3167
>>  > > > > >  ** mi...@mi...  *** www.mitra.biz **
>>  > > > > >
>>  > > > > >  **** Life is a mystery to be lived, not a problem to be
>>  > > > > > solved *****
>>  > > > > >
>>  > > > > >
>>  > > > > >
>>  > > > > >
>>  > > > > >  -------------------------------------------------------
>>  > > > > >  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
>>  > > > > Michael de Beer
>>  > > > > mi...@de...
>>  > > > >
>>  > > > >
>>  > > > > -------------------------------------------------------
>>  > > > > 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
>>  > > >
>>  > >
>>  > > --
>>  > > Setu <se...@oh...>
>>  > >   ICQ: 34839317
>>  > >    AIM: setu
>>  > >        MSN: set...@ho...
>>  > >       YAHOO: setu_prem
>>  >
>>  >
>>  >
>>  > --
>>  >  
>>  > 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
>>  >
>>
>>
>>
>>  --
>>  Setu <se...@oh...>
>>	ICQ: 34839317
>>	AIM: setu
>>	MSN: set...@ho...
>>	YAHOO: setu_prem
>>
>
>
>
>-------------------------------------------------------
>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