General mailing list for discussions and development of PeerLibrary and related software.

List archive Help


Re: [PeerLibrary dev] PeerDB vs. Meteor collection queries


Chronological Thread 
  • From: André Gaul < >
  • To:
  • Subject: Re: [PeerLibrary dev] PeerDB vs. Meteor collection queries
  • Date: Thu, 14 Aug 2014 15:52:33 +0200

Hey Mitar!

Am 14.08.2014 um 15:10 schrieb Mitar:
> If one store a reactive variable inside a created method onto
> template instance, and then have a template helper access that template
> instance and use value from the reactive variable, if reactive variable
> changes, does template helper rerenders?

You would have to define dependencies like in [1] but you write so much
code for stuff that should be really simple. But it's possible. By the
way: the new 'UI._templateInstance()' again is based on a global
variable. There's no parameter passed to a helper. But at least the new
hack allows to store data in the instance.

> URL should contain a global state of the application. If you copy-paste
> URL into another browser, you should get the same state, user interface,
> location of the publication, same dialog opens, etc. For PeerLibrary, I
> would imagine something like that:
>
> https://peerlibrary.org/path/which/determines/entity/we/are/showing/plus/maybe/slug?values&in&various&forms#hash_of_the_rest_of_the_ui_state

This might seem to be a good idea but it's not that easy because "URLs
over 2000 chars will not work in most popular web browsers" [2]. Also,
it's cumbersome to store some parts, e.g., which dialog boxes are open
or which strings are entered in which forms. And with userdata, you'll
exceed the 2000 char limit easily. Isn't a link to a certain publication
and an additional identifier (like the position in the doc) in the hash
part enough?

Don't get me wrong: having a session isn't bad at all for certain data,
e.g., information about the user's login state. But in my opinion, UI
components such as search fields should not store their data in global
variables.

> BTW, Meteor GitHub tickets are meant only for bug reports and not
> discussion. You should use meteor-talk or meteor-core mailing list for
> discussion. (In PeerLibrary is different and we prefer everything in one
> place.) (The only exception was for new Meteor templating engine Blaze,
> but even that they started discouraging.)

OK, thx.

> If you want to dive into one more aspect of Meteor, their use of fiber,
> pleas help me with this. I am stuck:
>
> https://stackoverflow.com/questions/25248493/how-to-use-fibers-with-streams

No idea about that one. ;)

cheers,
André


[1]
http://www.manuel-schoebel.com/blog/use-deps-dependency-instead-of-session-if-you-can
[2]
http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers
--
Homepage http://page.math.tu-berlin.de/~gaul
github https://github.com/andrenarchy
Twitter https://twitter.com/#!/andrenarchy
Diaspora https://diasp.org/u/andrenarchy
(you won't find me on facebook!)
Jabber

PGP Key 0x0FA9170E



Archive powered by MHonArc 2.6.18.

Top of page