[Feature request] Valid message id

Hi,

I noticed message ids are outputed as: <a name="8020"></a>

Is it possible to add some characters before the id in order to get a valid value (note that the "name" attribute is now depreciated for xhtml) ? Or better: remove the anchor and put an appropriate id like:

<div class="PhorumReadMessageBlock" id="message-8020">

See [www.w3.org] for more infos

Thanks

hmm from your link:
"Many existing HTML clients don't support the use of ID-type attributes in this way"

so we will probably still need to put both ways in.
is having a number only really invalid?

---

Thomas Seifert

Ids work with Netscape 4.07 released 7 years ago. They don't in Netscape 3 (1996)... well... actual phorum don't either :)

(Note that in dino browsers, phorum shows up &bull; instead of bullets. It would not happen with proper <ul> list. I bet the problem exists with some cellphone/pda browsers!)

are you sure that ids in (i.e.) a div called as anchors in a link work in ns4 too? I don't have it installed here to check.

---

Thomas Seifert

From my point of view the delevopers should say "Good Bye" to all browser older than 3 years. Phorum v5 should support und use the CSS Level 2 standards.

In the next weeks I guess I am very busy to find out how is the best way to integrate Ph5 to a XHTML confirm site. I don't hope that it will be a too hard work :-))

Once I finished it I will report the result here, but it will take a while!

---
Ciao
runner

You might want to look at the eugenol-template IMO it was made to be fully strict-validated.

---

Thomas Seifert

runner Wrote:
-------------------------------------------------------
> In the next weeks I guess I am very busy to find
> out how is the best way to integrate Ph5 to a
> XHTML confirm site. I don't hope that it will be a
> too hard work :-))

There you have an example: [www.eugenol.com]
Others will soon follow.

Template is available here: [phorum.org]

ts77 Wrote:
-------------------------------------------------------
> You might want to look at the eugenol-template IMO
> it was made to be fully strict-validated.

Exactly :) (but the exeption this thread deals with)

I will make it start with characters, making it an id or name is up to the template-authors IMO ... or are there places where the internals of phorum need to be changed for that too?

---

Thomas Seifert

Sure: all generated links ending with a fragment identifier:
- the "Last Post" link in list*.php
- generated URI in email notifying
- etc.

sure, this link will just get the same anchor.

I meant for the id / name -change in the templates there is no change in the links required, right?

---

Thomas Seifert

I'm not sure I got what you meant :)

- links should be like:
[phorum.org]

(no underscore allowed, so no #message_8891)

- and ids like:
<div class="PhorumReadMessageBlock" id="message-8891">

- or (very depreciated) anchors like:
<a name="message-8891">

In Eugenol theme, messages will then be identified like:
<h4 id="message-8991">Re: [Feature request] Valid message id</h4>



[OT]
BTW we still hesitate to use some xml approach and move the id from the <h4> tag to the <div class="message"> tag

Thinking about xml and a <message id="post-8891"> or <message><id>8891</id>(...)</message> export...



Edited 1 time(s). Last edit at 09/05/2004 12:43PM by Promopixel.

> - links should be like:
> [phorum.org]
> ge=2#message-8991

they are now (in cvs) #msg-8991

> - and ids like:
> <div class="PhorumReadMessageBlock"
> id="message-8891">

its name="msg-8891" ... changing it to "id" is in the eyes of the template-authors like you :).
I don't think it needs internal changes to use ID instead of NAME ... thats what I meant.

> In Eugenol theme, messages will then be identified
> like:
> <h4 id="message-8991">Re: Valid message
> id</h4>
>

make it msg-8991 and it will be ok (in 5.0.10 :))

>
>
>
> BTW we still hesitate to use some xml approach and
> move the id from the <h4> tag to the <div
> class="message"> tag
>
> Thinking about xml and a <message
> id="post-8891"> or
> <message><id>8891</id>(...)</
> message> export...

a xml-only template will be interesting too ;).



thomas

---

Thomas Seifert

As I first step into XML worlds we hope to release soon some ATOM and RSS1.0 exports of phorum.

like that:
[phorum.org]
and
[phorum.org]
? :)

---

Thomas Seifert

Not really :)

We think the ATOM feed needs more tags, and Brian's code a true utf-8 export.

We plan besides to rewrite first some native phorum functions into a true OOP design.

Haven't you BTW neved discussed about OOP ?

too much speed penalty with OOP.

---

Thomas Seifert

Which speed penalty for a forum ? You've already designed a tons of functions called by a tons of include/require ! :)

OOP for phorum doesn't mean building a smoking factory like Horde framework. There are numberless good examples like ADOdb (http://adodb.sourceforge.net/) which is very modular then fast and lightweight.

inc/* already got the taste of an API since every hacker use their functions for writing modules... Phorum is a big application, so procedural writing needs a lot of home made functions. You're very close to OOP but you do not reach its boundaries :)

Slow OOP is a myth. There is no doubt that if you abstract everything with OOP then Phorum will get slower, but that's another story.

> Which speed penalty for a forum ? You've already
> designed a tons of functions called by a tons of
> include/require ! :)

includes and functions will blow classes away in speed any day. You still have to include classes and they still include functions

> OOP for phorum doesn't mean building a smoking
> factory like Horde framework. There are numberless
> good examples like ADOdb
> (http://adodb.sourceforge.net/) which is very
> modular then fast and lightweight.

You have got to be kidding me. Before starting on Phorum 5, I tried ADOdb. Here were my results:

I thought about using a database generalization (I refuse to call them
abstraction) system.  Heh, then I tried adodb.

Straight PHP to select the newest 50 records from the phorum_support table:

Requests per second:    57.99 [#/sec] (mean)
Time per request:       51.73 [ms] (mean)

Then the adodb version:

Requests per second:    8.98 [#/sec] (mean)
Time per request:       334.00 [ms] (mean)

> Slow OOP is a myth. There is no doubt that if you
> abstract everything with OOP then Phorum will get
> slower, but that's another story.

So, which are you saying? That OOP is not slow or that Phorum will be slower?

Another thing. You need to very carefully read the license before you dive into changing all the Phorum code. You need to know what you can and can not do with that code.

Brian - Cowboy Ninja Coder - Personal Blog - Twitter

brianlmoon Wrote:
-------------------------------------------------------

> includes and functions will blow classes away in
> speed any day. You still have to include classes
> and they still include functions

That's why I said you're very close to an OOP API design.

> You have got to be kidding me. Before starting on
> Phorum 5, I tried ADOdb. Here were my results:I
> thought about using a database generalization (I
> refuse to call them
> abstraction) system. Heh, then I tried adodb.

I remember these times of Phorum4 then Phorum5 development. At this time ADOdb was versionned 1.x.
Times fly. I also benchmarked ADOdb with PEAR::DB (which also changes a lot since) and my procedural script from times to times. Now ADOdb is v4.5 and is THE db class reference. Anyway that's another story too (like if someone would say in 2004 phorum sucks but only v3.0 is installed).

> So, which are you saying? That OOP is not slow or
> that Phorum will be slower?

- That OOP is fast: you save CPU psec with procedural writing while you will save hours writing new modules or pages for Phorum with a strong OOP API.
- That you must not fall in the OOP trap with abstracting everything you can, because PHP is a slow scripting language after all.

> Another thing. You need to very carefully read
> the license before you dive into changing all the
> Phorum code. You need to know what you can and
> can not do with that code.

We read licences for every software we hack.

Best regards.

> - That OOP is fast: you save CPU psec with
> procedural writing while you will save hours
> writing new modules or pages for Phorum with a
> strong OOP API.

Perhaps you can explain this to me. How is knowing the Class structure of a project any "faster" than knowing the procedural API?

I have asked many OOP people this and they always just say it is because it is. If I know my function lib, It doesn't really matter if it is procedural or OOP.

Brian - Cowboy Ninja Coder - Personal Blog - Twitter

brianlmoon Wrote:
-------------------------------------------------------

> If I know my
> function lib, It doesn't really matter if it is
> procedural or OOP.

That's exactly the point! You exactly know how your API works since you're involved in.
What about new hackers ? What if you leave the project then work on it again 18 months later ? Can you garantee you'll understand what you've wrote ?

The API has a lack of documentation (javaDoc style is very simple to add) and OOP force you to think different and build pages with quite independant functions and no global vars.

OOP is of course stupid for simple scripts (unless the scripting programming language deals with objects everywhere like python or ruby). Is phorum just a script ? Or a real project ?

The point remains here: you've already designed an API and lots of hacker can see you're just a step from OOP. With a strong modelisation (which I don't have any idea here), phorum's files will then contain less code for same result (and less is beautiful, or less is more, choose your moto :) ).

If we have enough time, we'll try to show you in the next months how a forked OOP Phorum could be.