%EDITTABLE{header="on" format="| label, 0, nothing | label, 0, nothing | text, 30, job or task | select, 1, Free% SEARCH{search="Phone:.*321" web="Main" scope="body" regex="on" format=", Main.$topic" noheader="on" nosearch="on" nototal="on"}% |" changerows="off"}%
|*Machine* |*Location* | Purpose |*Reserved By*|
| eagle | 3840 | | Free |
| condor | 3690 | training demo | Main.Guest1 |
| woodpecker | 3330 | | Free |
| raptor | 3120 | customer demo | Main.JohnRouillard |
I get as output:
%EDITTABLE{header="on" format="| label, 0, nothing | label, 0, nothing | text, 30, job or task | select, 1, Free, GuestOne , GuestTwo , JohnRouillard |" changerows="off"}%
After the editable line is the regular table, no edit button.
If I put in the list of values just as spaced (note the extra space before the ,) the edittable
works fine. My WAG is that the % EDITTABLE% is parsed before the % SEARCH% is, and thus EDITTABLE
thinks its not being called properly. I am using boolwrapper as the fgrep engine as discussed in
SearchEngineVsGrepSearch, but I don't think that has any bearing on the failure of edittable,
but it could have some bearing on the extra spaces.
%SEARCH returns one line per search hit, this destroys TWiki tables and variables that contain the search.
Example search inside a table cell for topics containing "Plugin":
|
||
separator="" switch where you can define the separator between hits. The default is separator="$n"; in your case you would set it to separator=", ". This would be a useful enhancement. We can take it into the core code if you program this
-- PeterThoeny - 10 Aug 2002
Ok. Now I get it. I was looking at the rendered text and thinking it was entered the same way it was renderes.
Of course the newlines got wrapped out of existance in the rendered text. Sorry it was late, I obviuosly wasn't
thinking.
Well you can't integrate anything new that I write into core code. I'm still fighting copyright issues. Anything
new I write is currently tainted till things get resolved. That's why a lot of my changes are either one liners,
or only explain the problems without actually showing code to fix them. I am trying to not submit any fixes that
require new code to be written and integrated. That would be new work rather than fixes to existing prior work
which I can do under my contract.
-- JohnRouillard - 11 Aug 2002
Hmm, If I change the format to read format=", $topic\" would the "\" at the end cause the lines to be concatanated?
I'll try that and report back if nobody posts an answer before I get to work in a couple of hours.
-- JohnRouillard - 11 Aug 2002
Nope, no go. Tried \", got " and I think newline. Tried \\, got \" and newline. Each additional
\ gets me another \ before the quote int he output. Oh well it was worth a shot.
As an idea, what about using something like echo's "\c" command in the format string to suppress the
usual line ending character rather than having to add another parameter to the search interface. That may
require few enough changes to make it a bug fix rather than new development.
Now If I can find where the newline is being put into the result of $theFormat in Search::searchWeb maybe
I can patch this for my copy.
-- JohnRouillard - 11 Aug 2002