Gwayne: joined #tikiwiki Tiki-KGB: 03chibaguy r49332 10trunk/templates/ 10comment/list.tpl 10comment/post.tpl
[ENH] Added legend for fieldset, corrected typos, removed btn-group class because it made the comment-form div display:inline-block (so narrow instead of full-width). Gwayne: joined #tikiwiki
joined #tikiwiki redflo: joined #tikiwiki innoc: joined #tikiwiki innoc_: joined #tikiwiki Telesight: joined #tikiwiki xavi: joined #tikiwiki Tiki|bot: New Forum Posts: white page on show php error = no - http://suite.tiki.org/tiki-view_forum_thread.php?forumId=26&comments_parentId=50841
New Forum Posts: Column spacing question - http://suite.tiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=50839
New Forum Posts: Table tiki_shoutbox_words corrupt - http://suite.tiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=50838 arildb: joined #tikiwiki Tiki|bot: New Forum Posts: white page on show php error = no - http://tiki.org/tiki-view_forum_thread.php?forumId=26&comments_parentId=50841
New Forum Posts: Column spacing question - http://tiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=50839
New Forum Posts: Table tiki_shoutbox_words corrupt - http://tiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=50838 jonnyb: joined #tikiwiki
a hoy hoy fabricius: polom jonnyb: polom fabricius fabricius: hmm jonny, I think I have to discuss a few things with the lads
:-)
who is here? sadly LPH not, if I see right
jyhem, luciash jonnyb: a bit early for them i think fabricius: I make it short for wh feels concerned and hope to get some time for a brief e-mail to the dev list lateron
for who
A) I think we need some coding for Bootstrap Tiki13 components and there as soon as possible with menu/superfish <-> finish what LPH hardcoded
and
navbar!!!
B) I find wikiLingo from Robert Plummer very promising and I strongly feel, it could solve a lot of frustration which I experience over the time
It looks like, that we start an experimental branch, to check what would be the effort to implement it in Tiki
IF we would go that road - what I tend to like - that would most likely affect some or a lot of code of you jonnyb ... so I would like to get you into the discussion early, hope to get questions about the wikiLingo side from you and aswell your thoughts (same from the others)
one example, where I see that affecting, would be the "WikiSyntax in menu" thingi Tiki|bot: New Forum Posts: Running a site on two different SVN versions - http://tiki.org/tiki-view_forum_thread.php?forumId=26&comments_parentId=50850 fabricius: or the module/menu revamp prozess - the people working there would have to be asked and their opinions particularly considered
so that's for the moment jonnyb and all the others - any thoughts or questions or objections? arildb: hi fabricius .. some wikiLingo questions
1) can wikiLingo load/save wiki pages in html format
2) can wikiLingo operate alongside CkEditor? jonnyb: hi arildb arildb: hi jonnyb jonnyb: i think this is an alternative to ckeditor and the current wiki/html pages system fabricius: hi arildb .. I am notsure, if I understand fully, what you mean with load/save
arildb .. and let us make clear for now, that we talk in theory, so Tiki - wikiLingo in a possible experimental branch, not in trunk or so arildb: jonnyb: so the store data of wiki pages would use a "wikiLingo" syntax? fabricius: arildb: jonny is right
yes, if I might answer jonnyb: yes, it;'s a different version of a wiki, but similar to tiki fabricius: but the "wikiLingo" syntax is pretty much the same as the TikiSyntax arildb: right ... so all existing data must be converted, or? ... would this apply to all stored text? fabricius: there are different ideas jonnyb: not sure you can convert reliably fabricius: most text .. if I see it right .. would not have to be converted
but
there could be issues to be resolved with certain plugins arildb: having html syntax is (kind of) required for some systems that use 3rd party tools that understand html, but not wiki syntax .. and access the database directly fabricius: especially as some plugins can be written differently regarding the parameters
arildb: that is an interesting point
maybe you could give me some examples (maybe in dev-list), to bring that up
afaik the content usually would be saved in wikisyntax and not in html arildb: custom data analysis / search tools fall in this category fabricius: ok
how this is made today on a Tikisite that does not use CKE HTML_WYSIWYG?
I mean, I normally do not use wysiwyg in production and when I view the database, I see only wikisyntax in the tables - if I am not completely wrong arildb_: joined #tikiwiki fabricius: so from my individual perspective I would not face much change in that, but I would gain an optional wysiwyg behaviour just by using contenteditable and no need for cke anymore
I will bring up the use case, that saving in html would be necessary luciash: polom polom pom pom ! jonnyb: moq moq moloq luciash luciash: :) fabricius: wolod! luciash: yo fab
who is lad ?
ladies ? fabricius: hehe hehehe
no, lads and laddies Tiki-KGB: 03manivannans r49333 10branches/12.x/tiki-print.php
[FIX] Current pagename added as a pagetitle in tiki-print.php Ref: http://dev.tiki.org/item5047 fabricius: Irish English for guys or buddies luciash: aaah :) -: luciash thinks most universal would be saving the raw data in XML or JSON but that is a different story ... would need to see example of stored data in wikiLingo rodrigoprimo: joined #tikiwiki fabricius: luciash: arildb did bring up a similar idea ... stored data in wikiLingo looks pretty much identical than stored data in raw TikiWikiSyntax ... so the XML or JSON idea is definitely to be discussed
especially if that solves more yet unconsidered cases and makes the system more compatible without losing robustness arildb: using a widely used standard, e.g. HTML or XML as the base data format makes the raw data more accessible to 3rd party tools that access the database directly. Parsers are pretty much available in all (potential) client languages fabricius: what's about the wikiplugins? rodrigoprimo1: joined #tikiwiki arildb_: joined #tikiwiki Tiki|bot: New Forum Posts: Smarty template inheritance parse order problem - http://tiki.org/tiki-view_forum_thread.php?forumId=26&comments_parentId=50852 luciash: fabricius: what do u mean ?
fabricius: if you mean how would you store wikiplugin data in XML it could be something like <wikiplugin name='trackerlist' params='...'>plugin body content</wikiplugin> for example fabricius: in what syntax save the wikiPlugins in the database, in context of the discussion goes to possibly saving in XML ...
yeah, that luciash: in XML syntax fabricius: luciash: do you always need an end tag in XML? or is it possible to optionally use this: <wikiplugin name='trackerlist' params='...' /> ? luciash: some say (maybe lph ;-)) XML uses too much space so they prefer JSON ;-) fabricius: what's the difference? luciash: fabricius: it is valid fabricius: JSON or XML? luciash: fabricius: difference ? between XML and JSON ? fabricius: yes luciash: heheh, you should know already but JSON is something like bunch of curly brackets nested simmilar to JavaScript syntax ;-)
google JSON
you will find bunch of examples fabricius: I mean a possible decision between XML and JSON has (aswell) to do with compatibility and flexibility .. do we live more in a XML world or in a JSON world and has the "smaller" one huge advantages over the other?
hummm bunch of curly brackets ... in the last years and month I stumbled over articles about XML here and there - even SVG is some "dialect" of XML ... and when you say "curly brackets" I can imagine, that XML might be more the direction? nothing against curly brackets - I learn a lot of curly bracket stuff since a few weeks luciash: i would prefer XML because it is more natural to decipher in source code reading to me than JSON but JSON can be faster and smaller to store data so maybe that would be better
there can be also other options, these two are just "standard" examples
bunch of curly brackets is JSON, not XML ;-) fabricius: I mean, there are certain wide spread formats using or being based on XML or similar
"bunch of curly brackets is JSON, not XML" <- YES!! Did I misstype? luciash: ah, ok :) misunderstood
me fabricius: I mean XML might be more the direction people would go, cause it is non-curly luciash: but expect if you have 100MB database to grow it twice at least if you store in XML
i think fabricius: just quite flippantly expressed I mean
hummm .. I think then aswell a 4MB database and a 350MB database will grow twice? luciash: when i proposed to store pages data (wiki syntax) in XHTML in Tiki several years ago, the idea was quickly dismissed by others...
so good luck with this one ;-) redflo: left #tikiwiki arildb: XHTML ... yes, that sounds good Tiki-KGB: 03jonnybradley r49334 10branches/12.x/ 10styles/layout/design.css 10lib/toolbars/toolbarslib.php
[FIX] toolbars: Move colour picker CSS from the php to css file as $headerlib->add_css no longer necessarily works all the time (fixes wish5066) fabricius: luciash: i am just evaluating, getting thoughts, opinions and I learn in the process ... luciash: fabricius: you're doing good ! fabricius: luciash: not (yet?) trying to convince about s.th.
luciash: thx! marclaporte: joined #tikiwiki rodrigoprimo: joined #tikiwiki Tiki|bot: Recent Bug: - Submitted by field shows current user if empty - http://dev.tiki.org/item5089 Tiki-KGB: 03chibaguy r49335 10trunk/templates/comment/post.tpl
[FIX] Combining fieldset and .panel-body (and worse, legend and .panel-heading) causes unpredictable styling quirks, so reverted to using divs only. Thanks to gezza for reporting. robertplummer: joined #tikiwiki
polom
polom all (oops) jonnyb: hi robertplummer Tiki-KGB: 03jonnybradley r49336 10(5 files in 5 dirs) * [MRG] Automatic merge, branches/12.x 49329 to 49334 robertplummer: hi jonnyb , How are things on the other side of the lake? jonnyb: lots warmer here than your on side i hear, but quite wet and windy to make up for it :) robertplummer: jonnyb: 2 out of 3 aint bad. jonnyb: :) luciash: robertplummer: sunny spring here
:) marclaporte: joined #tikiwiki luciash: wb marclaporte :) marclaporte: :-) robertplummer: luciash: you are rubbing salt in my open wounds :P luciash: robertplummer: oops, sorry ! :) robertplummer: luciash: I'm just kidding.
luciash: Did my reply yesterday satisfy your curiosity? luciash: robertplummer: yes, thank you, sounded fair :) robertplummer: luciash: robert *wipes sweat from brow* luciash: robertplummer: if u by any chance read this irc log, you will find some more funny read from here robertplummer: ok luciash: today's log robertplummer: There was discussion about json and xml with wikiLingo possible?
I will read it now. luciash: yes
this is just a babytalk of clueless heads to you i suppose ;-) robertplummer: luciash: wikiLingo to alternate outputs is easy. In fact, at this time it assembles an object from the markup, so you could almost do a json_encode($parsed) and have it.
But more important, it an object before it is rendered. -: luciash is unsure if the data is stored in wikiLingo in the db table or wikiLingo is a layer above robertplummer: luciash: The wikiLingo markup looks just like tiki's, that is what you'd see in the db.
luciash: it is then parsed to an object, then the object is rendered to a string.
arildb: polom arildb: hi robertplummer robertplummer: arildb: You asked a couple of questions from fabricius, I can answer those if you like. arildb: robertplummer: please robertplummer: arildb: 1) Html is fine in wikiLingo, even in wysiwyg mode. This is because the html that is wikiLingo gets a bunch of extra parameters, these are url encoded so they don't conflict with html. But in short, these extra parameters associate the wikiLingo html with a php class.
However, if the html is just html, it is ignored. Somewhat it stays static.
However, there are some html that is considered by default as unsafe, like <script> or <link> or <iframe>, these are handed so that they will not execute when wikiLingo processes the page they are in. xavi: joined #tikiwiki robertplummer: arildb: But when these go back to the server from wysiwyg to wikiLingo, they are turned back into their unsafe types, this keeps the markup from being altered from how it was originally entered.
arildb: There are unit tests that point to how this works: http://wikilingodoesthat.com/demo/test.php
arildb: Click on the unit test name, to see the code that ran.
arildb: Look for "TagsUsedWithWikiLingo" arildb: robertplummer: checking robertplummer: arildb: 2) can wikiLingo operate alongside CkEditor? Yes. How I see it is that wikiLingo and CKEditor would still both be in use. CKEditor for older and existing pages that were created with it, and wikiLingo with new pages, with the option to use the old editor.
jonnyb + arildb : however that is only a suggestion. My goal is to make content more valuable, but break the content. I feel if you break content, you are no better than Microsoft, because that is what they apparently LOVE to do. arildb: robertplummer: try a unit test with <table border="1>...and so on robertplummer: arildb: You mean an unclosed border attribute? arildb: robertplummer: sorry <table border="1">...and so on. No, I meant maintaining the border attribute robertplummer: trying
arildb: Go here: http://wikilingodoesthat.com/demo/mirror.php arildb: checking robertplummer: arildb: imput this (or something to test your input) '__bold__ <strong style="border: 1px solid black;">bold</strong>' hrsms: joined #tikiwiki robertplummer: arildb: Scroll to the bottom of the page to see what was output when you click the output button. Be sure to test it with wysiwyg on an doff.
off arildb: checking robertplummer: arildb: You'll see that in the above example (I used a break that was filtered in the chat room) with wysiwyg on, I got this: '<strong class='element' data-type='WikiLingo\Expression\Bold' data-element='true'>bold</strong> <br class='element' data-type='WikiLingo\Expression\Line' data-element='true'/> <strong style="border: 1px solid black;">bold</strong>' arildb: unable to paste into the ikiLingo mirror robertplummer: arildb: What browser you using? It is just a textarea, nothing special. joelobrecht: joined #tikiwiki arildb: FF
works well ricks99: joined #tikiwiki arildb: Is the process ... robertplummer: arildb: I've never heard that browser ;) arildb: 1) Take the input and convert it into wikiLingo syntax robertplummer: arildb: yes. arildb: 2) Convert the wikiLingo syntax into out source? robertplummer: arildb: To see the whole process from wikiLingo -> wysiwyg html -> wikiLingo, check this out: http://wikilingodoesthat.com/demo/editor.php arildb: checking robertplummer: arildb: Now, it isn't perfect, but again, the biggest issues that we've had have been solved.
data transformation (which is HUGE!) and drag and drop.
as well as nesting plugins. arildb: robertplummer: I will take a closer look at it later. However, the stored page data using wikiLingo, will be in "wikiLingo" syntax, right? robertplummer: arildb: yes
arildb: If you need XML or JSON from the object, we could write a renderer for it, but that is just another output, just like html, or wysiwyg html. arildb: robertplummer: This seems to work well as long as wikiLingo is available. However, in systems where the Tiki database is directly accessed by 3rd party tools, having the data formatted in a "known" format is an advantage. HTML is then typically known. Wiki syntax is not. Tiki-KGB: 03jonnybradley r49337 10branches/12.x/lib/core/Tracker/Field/UserSelector.php
[FIX] trackers: If a record is missing from tiki_tracker_item_fields for a user selector then that item was showing as being "owned" by whoever the current user is, as seen on dev.tiki.org. Not setting the value to $user here fixes that, and editing & creating items still works as expected in view_tracker_item and the tracker plugin.
Should fix wish5089 robertplummer: arildb: You could also at time of edit parse what has been edited and save it in an alternate format, it would most likely be one way though. arildb: Is it possible to use an (say) XHTML syntax in the database, and still use the wikiLingo object model? robertplummer: arildb: It could potentially. With the 3rd party tool update the XHTML?
Would (not with) arildb: probably not
I don't know any such cases robertplummer: arildb: Then you'd just save the page's source at time of edit to another format so other places could read it. That is just how you'd do it in an enterprise system.
arildb: This cuts down on resources etc. but essentially to answer your question... Yes, you can.
The page would be saved in BOTH formats at time of save/edit.
(hypothetically speaking) arildb: robertplummer: So, a system could be configured to only write html syntax (enable read access yusing db), and still use wikiLingo? robertplummer: arildb: if you introduce write, you introduce another layer of translation, that can REALLY complicate things quickly. Read, though, would be fine.[16:46] robertplummer For the XHTML or HTML5 or JSON or XML, if they just needed to read, a renderer could be designed for such a system. arildb: robertplummer: but how is the renderer accessed, when the data is read using SQL from a different system? fabricius: arildb: not at all
at the time, when you save a page you output as for example XML
but instead of outputting to the browser, you output to the database robertplummer: fabricius: Thanks for clarifying, man you are a smart guy! fabricius: but not instead of the wikiLingo code - additionally Tiki-KGB: 03jonnybradley r49338 10branches/12.x/lib/core/Tracker/Field/Files.php * [FIX] trackers: Notices - $file['galleryId'] not set, so use $galleryId instead? ricks99: left #tikiwiki fabricius: thx robertplummer: that is why I always ask my "dumb" questions until you nearly go mad robertplummer: fabricius: Thanks to you, someone else besides me understands wikiLingo. arildb: outputting to the database ... hm-m. So, an extra copy of the page is created in the "expected" format ...maybe on demand...h-m fabricius: robertplummer: big concern would be to integrate without braking things - robustness and compatibility must be kind of golden rules
arildb: the bad thing with this approach would be, that a lot of data would be doubled, making the database bigger marclaporte: joined #tikiwiki arildb: fabricius: yes, that's certainly an issue marclapo1: joined #tikiwiki fabricius: arildb: the good thing would be the flexibility, cause wikiLingo "does not care about the output" you could mainly output to arbitrary formats ... given once translated / added to the lexicals and definitions
so one project activates XML, another company needs JSON and a third project needed both or another one arildb: but maybe, if we ignore the size and processing overhead, having the option to additionally create an output with the page in a different format sounds very nice. Maybe certain pages should be auto-created in pdf format. Would satisfy external read needs, I believe Jyhem: polom robertplummer: fabricius: Agreed, that is why I eventually forked my code from tiki, it was just too much of a change for the existing parser. I had been breaking things, and it just got ridiculous. jonnyb knows what I'm talking about, he was cleaning up my messes, someone unknown to me at the time.
polom Jyhem fabricius: as long as 'read only' tables as reflection of the initial "saved" read-wirte content tables jonnyb: :) arildb: writes can be forced through Tiki web services, as I see it fabricius: yes robertplummer and jonnyb should not at all be repeated
this should not be repeated I mean
arildb: a good point Tiki-KGB: 03jonnybradley r49339 10branches/12.x/lib/core/Tracker/Field/ItemsList.php
[FIX] trackers: If " Value Field ID" option on an ItemsList is set (as is the case in upgrades often) then check if the remote field is an ItemsLink one and ignore that option if so (thanks eromneg) Jyhem: from my limited experience of XML from when it was all the rage, it is really computationally intensive. So using it only as an alternate output storage whould probably lower the overall computational cost fabricius: principally - just thought about the same a few minutes ago - if some web service or connection would be created (mail in maybe?) you could write html into Tiki and wikiLingo saves that as wikiLingo Jyhem: No numbers, just my feeling wrt performance of PHP based XML parsers jonnyb: off to find food, bbl fabricius: Jyhem: still a good point - I have the feeling, that something is in sight that feels comfortable for all of us - more or less
an idea, how it could work Tiki-KGB: 03jonnybradley r49340 10trunk/lib/core/Tracker/Field/Files.php 10trunk/lib/core/Tracker/Field/UserSelector.php 10trunk/lib/core/Tracker/Field/ItemsList.php 10trunk * [MRG] Automatic merge, branches/12.x 49334 to 49339 fabricius: jonnyb: bon apetit jonnyb: thanks
(really going now ;) ) hrsms: arildb: I see the comment you made in my show.tiki instance http://hrsms-11204-5084.show.tikiwiki.org/tiki-index.php?page=Book+Owners. "I tested using FF and there are multiple HTML errors". What is "FF", please? arildb: FF = Firefox
hrsms: yes, using Firefox instead of FF in that context would have been better hrsms: Thanks. I thought maybe it was a debugging tool. I was guessing Firefox Firebug. arildb: on the previous "wikiLingo can output to 'anything'" ... this could open for push services to external systems robertplummer: arildb: It also cuts way down on resources, and by its nature is much more stable. luciash: jonnyb: u sure the autoassign still works after you removed that part of the UserSelector code ? hrsms: arildb: Did you see anything wrong with the way I set up the trackers, trackerlist plugins, or templates? (sorry to interupt your other discussion. I can wait for a reply. I just didn't want to miss the opportunity to ask.) fabricius: ah arildb just earlier on, you explained me an aspect of this ... remeber object model: >>things are broken down into the "semantic" elements, which then thereafter can be expressed in any "language" (read data)<< arildb: robertplummer: yes, there are several nice features.It will be interesting to see the experimental branch. Maybe a "page" should be set up to discuss the (possible) wikiLingo integration and track the experiences in the experimental branch? fabricius: /s/remeber/remember robertplummer: arildb: That is good, but this has to be a community push, not just me. arildb: hrsms: No, I didn't. Looked a little, but did not see anything wrong...but I am no tracker expert hrsms: arildb: Thanks for having looked Telesight: joined #tikiwiki fabricius: and arildb - for me it would be very helpful / important to more briefly understand, what exactly attracts you on wikiLingo ... you know, as I have to hold Roberts lecture at the FOSDEM ;-) arildb: robertplummer: the integration must be a community push yes, but the initial target for the experimental branch is to evaluate, not to complete, or? fabricius: robertplummer and arildb - evaluate and test and show I'd say arildb: fabricius: It is an attractive feature to: Be able to convert, on the fly, and to route the output to a database and (maybe?) to other "targets". fabricius: yes, for example to pdf
push a button and parse to a pdf file (somehow parsed to create/download)
or ePub robertplummer: arildb: I agree arildb: robertplummer: I have head mention of a PDF "output target". What is the status there?
robertplummer: Can a PDF input source be handled? robertplummer: arildb: input, no.
arildb: output yes fabricius: so arildb, do I understand you right, that your concern is less to have wikiLingo saved in HTML or XML or JSON etc. but to have an option to read the content directly in the database in tthose formats - even if eventually in "mirrored" tables? arildb: robertplummer: that's correct for the "external system" use case, but it is also the case of html input, e.g. from the mail-in feature. Will that work? robertplummer: arildb: wikiLingo handles html input just fine, but for exporting directly to pdf would would with wikiLingo using the object model at this time. Hypothetically you'd need to convert html to pdf, so potentially that page would be more of a wikiLingo -> html -> pdf rather than just wikiLingo -> pdf.
However, if the page were written just in wikiLingo, it would be a candidate of direct to pdf. arildb: I am thinking about the creation of copies in different format and routing these....wikiLingo works at the parser level. Should creation of copies and "routing" be done at parser level...or can this complicate things and "require" too many dependencies? luciash: it would require "save a copy in XYZ" everytime you edit a wiki page imho to keep the copy in sync with wikiLingo stored data jonnyb: joined #tikiwiki arildb: luciash: yes, good point luciash: (so an external application can work with that data and be sure it is the latest state of things)
it would be for sure a miliseconds behind and much heavier on server resources if enabled
bbl robertplummer: luciash: That is right.
arildb: I think the resources used for this would actually be quite minimal.
This is only done at time of page save, so not on every page load. arildb: page saves can become "expensive". Not good for inline editing where responsiveness is important (frequent saves are probable)
robertplummer: does wikiLingo run purely server side? ... or what does the system topology look like? robertplummer: arildb: At this time, it is purely in php, but the code was written in such a way it can be ported easily to other languages. Right now the possible languages are javascript, php (which exists), and c#. Those are the langauge that Jison exists in, it is the backbone of wikiLingo.
arildb: I want to get the code into c# at some point to get more funding for the whole project. The business worlds embraces c#. arildb: robertplummer: right. Thanks robertplummer: arildb: always a pleasure. arildb: robertplummer: Does the development environment for wikiLingo have special requirements, like I believe the Jison parser has? robertplummer: arildb: For the most part no, just good ole fashioned php. If you want to start changing syntax or change how the parser works, then yes.
You'd need node.js + jison
jison can be install via NPM ricks99_: joined #tikiwiki robertplummer: (node package manager) -: luciash is back arildb: robertplummer: If I pull Tiki from SVN, then I guess a compiled and compatible "language definition" will also be downloaded. Is that how it will work?
...or will node.js be required to run the svn versions of Tiki? robertplummer: arildb: Well, wikiLingo is just a seperate project, hosted on github. You could start integrating from there. Jison is ran against the ".jison" files in wikiLingo, it outputs a js file and a php file. arildb: right ricks99__: joined #tikiwiki arildb: robertplummer: In Tiki syntax the table definition is like | ..is wikiLingo similar? ... sorry lot's of questions pop up...hope it's ok
The "border" attribute was kept in the wikiLingo test site, which is not possible in wiki syntax (Using | characters). How does wikiLingo solve it? robertplummer: arildb: magic
arildb: jk
arildb: Remember the syntax I sent you earlier that had the "data-type" attribute?
arildb: wikiLingo knows that this is a class type, and based off that, we know how to translate it back into wikiLingo.
arildb: Much of that is handled here: https://github.com/wikiLingo/wikiLingo/blob/master/WYSIWYGWikiLingo/Expression/Element.php arildb: robertplummer: is this data available in the database? is local css required to get the effect? robertplummer: arildb: In WYSIWYGWikiLingo (which is the translator that going from WYSIWYG to wikiLingo) there are just a few types. One of these types is called an "Element" (see the php file above).
arildb: Elements can be of a few different types: data-parent, data-element, data-helper, and static.
arildb: data-parent are used with lists and hierarchy, data-element is an element associated with a wiki expression (or markup), data-helper is something that is removed (that aids in the wysiwyg, but only there), and static - which is a standard user-entered html element.
arildb: Based off that, WYSIWYGWikiLingo knows to remove it, to use it as a markup, or to ignore it as html.
arildb: If the data-element has a data-type set, it is linked here: https://github.com/wikiLingo/wikiLingo/tree/master/WYSIWYGWikiLingo/SyntaxGenerator
You'll notice how complex it is for example to achieve BOLD - https://github.com/wikiLingo/wikiLingo/blob/master/WYSIWYGWikiLingo/SyntaxGenerator/Bold.php
It is extremely complex, all 17 lines of it. :P
It is essentially a 1 liner "return '__' . $this->expression->renderedChildren . '__';" and done. arildb: robertplummer: is this (e.g.table formatting data) stored as metadata or is it a part of the stored wiki pagedata? robertplummer: arildb: the html is stored as html, no trickery going on here.
arildb: When we say wikiLingo source, it is just that, wikiLingo source. arildb: robertplummer: Thanks a lot for your patience and answers. wikiLingo is clearer now. Getting a bite to eat now. Talk to you later robertplummer: ok ricks99__: left #tikiwiki Tiki-KGB: 03jonnybradley r49341 10branches/12.x/ 10lib/wiki-plugins/wikiplugin_img.php 10tiki-edit_draw.php
[FIX] draw: Use "special" get_perm_object call to get file gallery perms as Perms::get doesn't know about user gallery perms in img and edit_draw (where perms weren't being checked properly before anyway) - should fix wish5077, thanks again eromneg arildb_: joined #tikiwiki hrsms: arildb: Do you know any tracker experts that would be willing to look at the item we were discussing? Even just long enough to confirm it is a bug or my mistake? I am tantalizingly close to finishing this project. It would be great to either finish it, or put it out of my mind if I must wait for a fix. I don't see any workaround. jonnyb: hi hrsms - is it very complicated? i have a few minutes "spare" arildb: hrsms: There are clearly HTML errors on the page. So, something is wrong hrsms: jonnyb: the set up is quite simple. Understanding the behavior is not (for me).
The description is here: http://hrsms-11204-5084.show.tikiwiki.org/tiki-index.php?page=Book+Owners jonnyb: ok hrsms - checking... hrsms: arildb: I understand. But do they result from invalid use of the plugins/templates or from a bug? Well, even if invalid use I would say it is a bug, but one of a different sort. If it is not expected to work it should fail more gracefully (with message). If it expected to work, it is a worse form of bug. jonnyb: so these Owners are not tiki users necessarily? hrsms: In my case they are. But to demonstrate I wasn't going to create actual user accounts.
When I say "my case" I mean in my permanent tiki instance, of course. arildb: hrsms: html errors should not occur. They are probably caused by a system bug xavi: joined #tikiwiki hrsms: jonnydb: In the show instance the user ID is a numeric field. In my "real" case it is a user selector field. The behavior is the same. jonnyb: ok, so it's the nested pretty trackers thing - never easy... Tiki|bot: Recent Bug: - Add link to email to remove from watch lists - http://dev.tiki.org/item5090 jonnyb: it's probably a bug - that kind of thing worked in tiki 6 before the tracker revamp, but i've not really (needed to) try it since hrsms: I see the problem even when the inner use of the pluginTrackerlist does not use a pretty tracker. In other words, both of these fail: (tracker inside a pretty tracker) and (pretty tracker inside a pretty tracker)
If I'm the first to complain about it since Tiki 6, does that imply I'm going about this the wrong way?
Hard to believe I'm the only one with this basic type of goal jonnyb: each book only has once owner, right? So why not just have an owner ItemLink field on the book tracker?
huh? once = "only one"
bloomin autocorrect, grrr hrsms: No. Wee bit of background. I am a member of a ship model club. I created and maintain a website for the club. I wanted to create a list of references of interest to our members and visitors. You can see that here: http://www.hrsms.org/home/References (more...)
I also wanted our users to be able to create a list of the references they own, so they can keep reading lists, make private notes, etc.
Multiple people can own copies of the same book. So that is why I took this approach. jonnyb: ok, fair enough hrsms: So, it appears the conclusion is that it is a bug. I'll just have to wait for it to get to the top of the stack...
Thanks for looking jonnyb: i think it is a bug, but i have to go - will try and download the show instance an see what's happening in it
nice looking site by the way :) hrsms: OK. Thanks again.
Thank you. jonnyb: my grandfather used to make model ships :) hrsms: That's very gratefying to hear !! arildb: hrsms: If you need a multi-to-multi relation, you may need a link table....unless trackers magically handles this... I believe you had a direct link hrsms: arildb: Not 100% certain I know what you mean, but I think I have it. There is one tracker (table) for users. Another tracker for the books (which reference other trackers for lists of authors, publishers, etc), and a third tracker to tie the users to the books. jonnyb: trackers can do multi-to-multi using Relations fields without a join table/tracker
ok, off now - more tomorrow hrsms: This is all overkill for my little club, but it is a fun challenge to make it work they way I think it should.
I'm out too. Thanks for the help. arildb_: joined #tikiwiki
joined #tikiwiki arildb__: joined #tikiwiki fabricius: what is a join table/tracker xavi: left #tikiwiki fabricius: joined #tikiwiki redflo: joined #tikiwiki fabricius: joined #tikiwiki
joined #tikiwiki