**** BEGIN LOGGING AT Fri Sep 06 02:59:59 2013 Sep 06 10:52:15 afternoon Sep 06 13:52:13 hello everyone! Sep 06 14:14:44 Hello dimitrk Sep 06 14:14:51 :) Sep 06 14:15:18 I saw your server's setup process pjetr, nice job! :) Sep 06 14:15:25 I read* Sep 06 14:16:09 thanks, I've just updated it, since the owncloud setup installed an old version that isn't supported by any of the apps Sep 06 14:17:37 very nice ! Sep 06 14:18:02 this was al easy, I've tried e-mail Sep 06 14:18:26 that seems to be a different story Sep 06 14:18:49 you wanted to set up your own mail server? Sep 06 14:20:00 I remember I did it before, was a bit tricky at the beginning but once you start digging more started making sense the whole setup Sep 06 14:26:03 That's what I'm hoping for :) Sep 06 14:27:02 but I haven't got a domain yet, and it seems like it would be a whole lot easier with a domain Sep 06 14:27:11 at first glance Sep 06 15:12:54 have a great weekend all Sep 06 15:13:21 you too pjetr Sep 06 18:04:35 I was looking but I have hard time finding something. Does Enyo support data-* attributes? Sep 06 18:26:04 what are data- attributes? Sep 06 18:26:10 is that an MVC thing? Sep 06 18:26:39 no is an html5 thing Sep 06 18:27:38 but is ok, I found the setAttribute/getAttribute which do the same thing more or less Sep 06 19:01:14 dimitrk: you can also set attributes on a kind when you declare it with {kind: "XYZ", attributes: {thing1: "test", thing2: "test", ...}, ...} Sep 06 19:03:37 any particular reason you want them rather than published properties of kinds? Sep 06 19:04:23 thanks summatusmentis . Previously I tried something like that but it didn't worked. Maybe I did it wrong because I did something like attributes: Sep 06 19:04:47 attributes: { data: {prop1:"XYZ"} } Sep 06 19:05:09 yeah, I don't think you can do that Sep 06 19:05:10 I want them to keep some state of the control which is used for inner workings Sep 06 19:05:48 published are exposing handlers to the external controls and I dont want to pollute my controls with internal memory properties Sep 06 19:06:22 therefor I want to use attributes to keep states or any other piece of data Sep 06 19:08:20 oh, I see Sep 06 19:08:33 meh, I usually just use properties Sep 06 19:09:10 which can be modified by functions in other external controls, right ? Sep 06 19:09:51 Yea, honestly, I feel you are overcomplicating things by using attributes Sep 06 19:10:25 also, I've never heard of being able to put objects in attributes Sep 06 19:10:28 is that new? Sep 06 19:10:47 no, is not, my intention was not to put an object in there Sep 06 19:11:19 that's what you did in your example Sep 06 19:11:20 I thought that enyo has some wrapper in attributes object which iron it out to a string formatted as data-[key] Sep 06 19:11:21 dimitrk: they _can_, but you have to programmatically do so Sep 06 19:12:09 dimitrk: I don't think it's really a wrapper, I think they just flatten the key0value pairs Sep 06 19:12:20 yes for flattening.. Sep 06 19:12:36 so dimitrk, let's come up with some really simple example Sep 06 19:12:37 so was a shot in the dark to see if it will flatten an object Sep 06 19:12:39 I don't think it goes deeper than the first level Sep 06 19:12:47 So I can understand what you want to do Sep 06 19:13:23 Now i already did what I wanted to do. setAttribute("data-mykey", "someVal") Sep 06 19:13:27 Because right now, I'm not seeing why you wouldn't use a property Sep 06 19:13:52 properties are exposed and I feel that will be too much confusion to expose everything Sep 06 19:13:59 I want internal states to be internal Sep 06 19:14:08 and external properties to be externals Sep 06 19:14:18 so in other words Sep 06 19:14:25 you want encapsulation Sep 06 19:14:47 consider it like this. Sep 06 19:15:10 encapsulation in enyo modules is kinda different Sep 06 19:15:21 GodGinrai: d'you use Java? he's thinking about it in terms of public fields and private fields Sep 06 19:15:34 or rather, fields exposed via getters and setters, vs. not Sep 06 19:15:36 summatusmentis: that's what I'm getting at Sep 06 19:15:55 that's encapsulation Sep 06 19:15:59 yes Sep 06 19:16:27 except that encapsulation in Enyo means not reaching into other kinds and messing with it Sep 06 19:16:39 yeap Sep 06 19:16:39 (at least in how they talk about using it) Sep 06 19:17:01 No, encapsulation in Enyo means the developer must ACT like it is encapsulated Sep 06 19:17:02 published fields are still a part of how Enyo talks about encapsulation Sep 06 19:17:24 I believe is not directly modifying inner parts of a module Sep 06 19:17:24 rather than be forced to deal with the fact they can't get to it Sep 06 19:17:36 yes, that's true Sep 06 19:18:04 but that's the point, he wants "real" encapsulation, or at least more encapsulation than Enyo supports OOTB Sep 06 19:18:20 this is honestly a problem with Javascript Sep 06 19:18:24 I ll give an example Sep 06 19:18:36 there is no such concept in the language Sep 06 19:18:39 yes it may be but in other circumstances can be achieved with closures Sep 06 19:18:56 o_ô Sep 06 19:19:19 how would you achieve it with closures? Sep 06 19:19:48 is there less of a storage footprint by putting it in the DOM vs. in JS memory? Sep 06 19:20:10 for example consider this : function Car() { var canbreak = true; this.break = function(){ if(canbreak) {console.log("Stopped");} } } Sep 06 19:20:26 none can modify the canbreak value Sep 06 19:21:11 is local inner working. Is an internal state of a car and none has to know or has to modify this state because is there for the inner logic of the car Sep 06 19:21:32 when you say : var car = new Car() Sep 06 19:21:46 nothing can allow you to change the canbreak Sep 06 19:23:25 no in modules where a state value can be shared among many fucntions is used to be stored as a property. In enyo every property is exposed by default , no matter what is its role so is used to put some underscores __property to state the private Sep 06 19:23:41 I dont fancy so much this logic Sep 06 19:24:26 I actually just put anything I want to be public in the published object Sep 06 19:24:42 and all private variables outside of it Sep 06 19:25:18 along with your methods, right ? Sep 06 19:25:56 yes Sep 06 19:26:09 that's a good point Sep 06 19:26:23 you don't have to put things in published, you could just attach them to the kind Sep 06 19:26:29 which won't create getters and setters Sep 06 19:26:30 Now, here's my question: Have you checked if you can define your variables in the constructor? Sep 06 19:26:31 enyo.kind({ name:"some.name", published: {.....}, components:[...], privateProp: "val", makeHippoDance: function(){...} }) Sep 06 19:26:34 something like this Sep 06 19:26:49 yup Sep 06 19:27:11 I know, me too :P I dont fancy that way though Sep 06 19:27:24 GodGinrai: I don't think putting something in the constructor will do what he wants Sep 06 19:27:26 if I put them in my constructor you mean in my "Create:" Sep 06 19:27:27 ? Sep 06 19:27:33 is the same effect Sep 06 19:27:39 oh ok Sep 06 19:27:40 no, there is a constructor Sep 06 19:27:42 it's eitehr locally scoped, or global isn't it? Sep 06 19:27:45 on constructor , still the same Sep 06 19:27:50 that is before create Sep 06 19:27:56 yes yes , still the same Sep 06 19:28:01 therefor "constructor" Sep 06 19:29:06 for private functions I am using closures as I ve shown you before. this is dead end though when a private function can be used accross different public methods Sep 06 19:29:44 then I am forced to expose it. When it comes to properties situation is the same... usually are storing states of the module and you need to use them across many public methods Sep 06 19:29:57 so one way is the one that GodGinrai said Sep 06 19:30:19 but I would preffer something more "isolated that is why I am after data attributes" **** ENDING LOGGING AT Sat Sep 07 02:59:59 2013