[fossil-users] baseURI $baseurl/$current_page

[John L. Poole]

The default text in the Edit Page Header has:




What is the purpose of defining DOM's baseURI to the $baseurl/$current_page?




___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Constructing Base URI With TH1 Variables

[John L. Poole]

On 7/17/2016 7:10 AM, John L. Poole wrote:




On 7/17/2016 12:45 AM, Ron W wrote:
On Sun, Jul 17, 2016 at 2:08 AM, John L. Poole <jlpool...@gmail.com 
<mailto:jlpool...@gmail.com>> wrote:


On your suggestion, I inserted code on the setup_header page to this:


if {[hascap r]} {
html "\n"
}



And that worked: the baseURI variable in DOM was set to
"http://themis:8080/tktview?name=149873cca9;
<http://themis:8080/tktview?name=149873cca9>

However, each page now complains
"ERROR: no such variable: tkt_uuid"
and is missing styling and the heading matter.


Test $current_page for "tktview". If true:
html "\n"
else:
html "\n"


Thank you, that worked.  Here's what I used:



if {$current_page eq "tktview"} {
  html "\n"
} else {
  html ""
}


...

Caveat: changing the baseURI value to a specific ticket page 
introduced a problem in that ticketview pages are not having their CSS 
files loading correctly; the URIs for the CSS assume the baseURI to be 
$baseurl/$current_page.  I'll have to go down the line and introduce 
$baseurl/$current_page prefixes to URIs that assume that the baseURI 
has been set to $baseurl/$current_page




Trying  to use the variable $tkt_uuid in the header results in the error 
message
"ERROR: no such variable: tkt_uuid" and setting TH_ERROR and that, in 
turn, causes the rest of

the header processing function style_header() [style.c]  to be abandoned.

By happenstance, not redefining the baseURI with the tag  is 
the better approach, for now.
This is because the natural course of events will cause the DOM variable 
baseURI to be set to
the specific ticket page and then the SVG resolver properly can access 
the predeclared nodes within

the SVG.

This is what I ended up having in Edit Page Header section:

 


if {$current_page eq "tktview"} {
# do not change the baseURI so that embedded SVG markers properly resolve
} else {
  html ""
}

$: $

And now the page displays the SVG properly and the CSS formatting 
works.  I wonder what
cost this will be as there must have been a reason for redefining the 
baseURI.


For propriety, here are my notes in analyzing this:
tkt.c 443 commences the generation of the page. Line 482 calls 
style_header("View Ticket")

located at style.c 387.
style_header() at 424 calls  Th_Render(zHeader) [th_main.c 2300]
Th_Render calls Th_GetVar(g.interp, (char*)zVar, nVar) [th.c 1234] and 
when Th_GetVar()
determines the variable is not defined set TH_ERROR which results in 
sendError() [th_main.c 333]

being called and 337-341 cause the error output to display on the page.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Constructing Base URI With TH1 Variables

[John L. Poole]

On 7/17/2016 12:45 AM, Ron W wrote:
On Sun, Jul 17, 2016 at 2:08 AM, John L. Poole <jlpool...@gmail.com 
<mailto:jlpool...@gmail.com>> wrote:


On your suggestion, I inserted code on the setup_header page to this:


if {[hascap r]} {
html "\n"
}



And that worked: the baseURI variable in DOM was set to
"http://themis:8080/tktview?name=149873cca9;
<http://themis:8080/tktview?name=149873cca9>

However, each page now complains
"ERROR: no such variable: tkt_uuid"
and is missing styling and the heading matter.


Test $current_page for "tktview". If true:
html "\n"
else:
html "\n"


Thank you, that worked.  Here's what I used:



if {$current_page eq "tktview"} {
  html "\n"
} else {
  html ""
}


...

Caveat: changing the baseURI value to a specific ticket page introduced 
a problem in that ticketview pages are not having their CSS files 
loading correctly; the URIs for the CSS assume the baseURI to be 
$baseurl/$current_page.  I'll have to go down the line and introduce 
$baseurl/$current_page prefixes to URIs that assume that the baseURI has 
been set to $baseurl/$current_page


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Constructing Base URI With TH1 Variables

[John L. Poole]

On 7/16/2016 8:20 PM, Ron W wrote:
On Sat, Jul 16, 2016 at 1:49 PM, John L. Poole <jlpool...@gmail.com 
<mailto:jlpool...@gmail.com>> wrote:


The Edit Page Header allows one to define an HTML page 
element's child
using TH1 variables:

   

[...]

But the Base URI as defined by the above concatenation is really:

http://themis:8080/tktview

since $current_page is valued at "tkview".

What I'd like is to have a TH1 variable that allows me to
construct a value like"tkview?name=149873cca9" or
"tkview/149873cca9e566ab28d2b9922e44a515a639c3ff
<view-source:http://themis:8080/tktview>"


You can specify the TH1 and HTML for tktview. In that, you will have a 
variable with the ticket ID (don't recall name right now and replying 
from my tablet), so could build the URL using it.



Thank you.

On your suggestion, I inserted code on the setup_header page to this:

 


if {[hascap r]} {
html "\n"
}



And that worked: the baseURI variable in DOM was set to
"http://themis:8080/tktview?name=149873cca9;

However, each page now complains
"ERROR: no such variable: tkt_uuid"
and is missing styling and the heading matter.

I had tried to have the  element inserted from the Ticket View 
page,
but I think the first definition of  prevails, so that 
subsequent declarations

such as might be before the Ticket table is ignored.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Constructing Base URI With TH1 Variables

[John L. Poole]

The Edit Page Header allows one to define an HTML page  element's 
child

using TH1 variables:

   

THE QUESTION:
Is there a TH1 variable that contains the a more accurate address of the 
page?

For example, when viewing a specific ticket, the URL might be:

http://themis:8080/tktview/149873cca9e566ab28d2b9922e44a515a639c3ff

or

   http://themis:8080/tktview?name=149873cca9

But the Base URI as defined by the above concatenation is really:

   http://themis:8080/tktview

since $current_page is valued at "tkview".

What I'd like is to have a TH1 variable that allows me to construct a 
value like"tkview?name=149873cca9" or 
"tkview/149873cca9e566ab28d2b9922e44a515a639c3ff 
"


THE PROBLEM:

The problem I am experiencing concerns  elements and the mechanism
where internal markers are resolved.  For example, if I have an SVG that 
contains
a line with an arrowhead, the construction is basically a line element 
with an

additional marker that has to be resolved within the .

Here's an simple working example SVG:

http://www.w3.org/2000/svg; 
xmlns:svg="http://www.w3.org/2000/svg;>

 
 
  viewBox="0 0 100 100" se_type="rightarrow" orient="auto" 
markerUnits="strokeWidth" id="se_marker_end_svg_1">
   d="m100,50l-100,40l30,-40l-30,-40z">

  
 
 
  Layer 1
  x2="230" y1="50" x1="100" fill-opacity="0" stroke-linecap="null" 
stroke-linejoin="null" stroke-dasharray="null" stroke-width="5" 
stroke="#ff" fill="none">

 


The marker-end attribute of the  tag contains a function "url()" 
which references an internal  element as defined within the 
SVG's   element.  In order to properly resolve, the Base URI needs 
to be to the specific document.
Try added the above ... into a ticket in HTML mode and notice 
that in the "preview" mode, the arrowhead will appear, whereas if you 
save the ticket, the line will display without an arrowhead.  This is 
because the Base URI defined does not correlate with whatever mechanism 
the url() function uses.


I found that if I open an already saved Ticket where the line is missing 
the arrowheads, I can alter the HTML's Base URI from:
 http://themis:8080/tktview 
" />

to:
href="http://themis:8080/tktview/149873cca9e566ab28d2b9922e44a515a639c3ff 
" />


or to:

http://themis:8080/tktview?name=149873cca9 
" />


and the arrowhead will display.

Likewise, I can edit within the SVG the value for the marker-end 
attribute from:


url(#se_marker_end_svg_1)
to:

url(http://themis:8080/tktview?name=149873cca9#se_marker_end_svg_1)

and then the arrowhead displays.


-- John Poole


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Wiki Header Footers

[John L. Poole]

The Wiki Headers and Footers are not under any versioning control or 
history, correct?
I am planning on creating a file to source control them, but wanted to 
make sure I'm not doing something that is already built in.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Filtered Attribute of HTML tag in Wiki Rendering

[John L. Poole]

On 7/22/2015 10:33 PM, Stephan Beal wrote:
On Thu, Jul 23, 2015 at 6:35 AM, John Laurence Poole 
jlpool...@gmail.com mailto:jlpool...@gmail.com wrote:


pre src=http://localhost;default text here/pre

The attribute is and it value are removed.

Where would this filtering of attributes be occurring?  I'd like
to see if I can specify that is is a valid attribute.


See:

http://fossil-scm.org/index.html/wiki_rules

In particular, point #6 in the 2nd list. Relatively few HTML 
attributes are allowed by the wiki. There is another option, though: 
under Admin == Configuration is an option to Use HTML as wiki markup 
language, in which case all HTML is allowed.


Thank you.

Your points allowed me to go forward and my custom HTML5 tag
based on pre worked.  After  I posted my initial question, I found the 
file that probably is

controlling on the allowed attributes:

src/wikiformat.c 
http://fossil-scm.org/index.html/finfo?name=src/wikiformat.c


I am wondering if allowing the is attribute might allow customization 
while not jeopardizing security.

A TODO project, perhaps.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] DB Schema

[John L. Poole]

On Thu, Jan 13, 2011 at 2:16 PM, David Bovill da...@architex.tv wrote:


Quick question - is there a schema, or some description of the db structure
on the wiki I can take a look at?


I, too, had this question and found what I sought, ** The schema for a repository 
database.
in the source file

src/schema.c

For example: https://www.fossil-scm.org/fossil/artifact/cae75601dd0b3940

The file contains the SQL for creating the tables in SQLite; there are
comments included therein.


-- John Poole

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Gentoo: SQLITE_WARNING... best approach for Portage

[John L. Poole]

On Gentoo Linux, I created a custom ebuild to 2013-09-11 11:43:49, 
2013094349,  the version offered at 
http://www.fossil-scm.org/download.html.  An ebuild is basically a 
recipe or install script for a package manager to download and install a 
project software.  The package management system on Gentoo is called 
Portage and this is one of the main reasons I use Gentoo -- the 
convenience Portage provides making installing open source projects a 
breeze.   Currently Gentoo's official Portage tree offers version 
20130216000435 of Fossil at 
http://packages.gentoo.org/package/dev-vcs/fossil.  I decided to create 
a custom ebuild as I wanted to get the latest and greatest release of fossil


To create a custom ebuild in Gentoo, one can take an existing ebuild 
file and simply change its version and then see if it installs. 
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3chap=5#doc_chap2


I tried using the 20130216000435 release as a template for the and had 
to remove a reference markdown.  Otherwise, I successfully installed 
fossil 2013094349 using my custom ebuild.  Then when I went to 
follow the Quick Start at 
http://www.fossil-scm.org/fossil/doc/trunk/www/quickstart.wiki I ran 
into the SQLITE_WARNING: file renamed while opening: /root/[project name]


This SQLITE_WARNING issue was recently vetted on this mail list 
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg13410.html.


Gentoo offers the ability to follow a trunk line of code development on 
a project, but that feature is only for the not-so-feint of heart and 
discourage for obvious reasons.  The better practice is to target a 
project's release, such as Fossil's 2013-09-11 11:43:49 and thereby 
reaching a broader audience.  Portage can incorporate patches to a 
particular release.


The reason I'm writing to this list is to inquire if there will be a new 
release coming shortly or if I should try to create an ebuild that 
incorporates the patch that fixes this problem?  I'd like to see 
Gentoo's Portage contain the current release of Fossil.   I do not want 
to submit my ebuild to Gentoo until I know what I have created works.  I 
also don't want to spend the time if a new release is shortly around the 
corner, e.g. within several weeks.  If a new release is not imminent, it 
would be a tremendous help if someone were to provide me a patch file 
for your 2013-09-11 11:43:49 release.  I confess I'm not experienced in 
applying patches to Gentoo ebuilds, but I'm willing to try.


John


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users