Titanium JIRA Archive
Alloy (ALOY)

[ALOY-1363] Add support to set object properties via XML

GitHub Issuen/a
TypeNew Feature
PriorityCritical
StatusClosed
ResolutionFixed
Resolution Date2019-06-20T21:51:55.000+0000
Affected Version/sn/a
Fix Version/sCLI Release 7.1.0, Alloy 1.14.0
ComponentsXML
Labelsalloy, font, fontfamily, fontsize, xml
ReporterBrenton House
AssigneeBrenton House
Created2016-02-29T23:23:16.000+0000
Updated2019-06-20T21:51:55.000+0000

Description

Currently object properties like font.fontFamily or region.latitude can only be set in TSS. The request is to make this possible in XML as well, e.g.: 
<Label font.fontFamily="Roboto">Hello</Label>

Original description

As a developer, I want to be able to set font properties for a view from the xml view, So that I can often avoid creating controller files and keep view properties together. Desired xml usage: 
<Alloy>
    <Label fontFamily="Roboto" fontSize="12sp" fontStyle="italic" fontWeight="bold" text="This is test 1" />
    <Label textStyle="Titanium.UI.TEXT_STYLE_HEADLINE" text="This is test 2" />
</Alloy>
When processed, this should create a font object and properly merge this with any style objects defined. Added PR: https://github.com/appcelerator/alloy/pull/764

Comments

  1. Fokke Zandbergen 2016-03-01

    Apart from the fact that setting styles in XML is a bad practice, I'd rather see a more generic implementation for assigning object properties via XML: 
       <Label font:fontFamily="Roboto" />
  2. Brenton House 2016-03-01

    I like the idea of using xml prefixes to distinguish things. I think that would have been a good way to implement module and namespace support in Alloy tags. Are there a lot of other child object, other than font, that need to be set in xml? I noticed that setting font seems to be one of the few commonly used properties that can't be set currently using the normal xml attributes.
  3. Fokke Zandbergen 2016-03-01

    Another example could be region/position of Maps/StreetView. But more importantly fixing it that way would make it more future proof
  4. Sharif AbuDarda 2016-03-01

    Though it's a bad practice not to set styles in TSS than XML. This is a valid PR. Thanks.
  5. Brenton House 2016-03-01

    I guess I agree to disagree on the bad practice. What exactly are you considering to be "styles" vs. normal properties? It doesn't seem like a good idea to force developers to create a TSS file just to set one property of a view.
  6. Sharif AbuDarda 2016-03-01

    The Titanium Style Sheets (TSS) file uses a JSON-like syntax to define the attributes of elements in the XML files. All TSS attributes are the properties of the Titanium object. For examples, when defining the style for a Button object, each property, such as backgroundDisabledColor, backgroundFocusedColor, backgroundSelectedColor, etc., can be specified as an attribute in the TSS file. You can either use tss or xml to set a property of a Titanium obsject. But when you want the Platform-Specific Styles and Custom Query Styles you would need a tss file to set up those conditions. Thanks.
  7. Brenton House 2016-03-01

    I understand what the TSS files are, I just disagree that we should be forced to use them :) The fact that they are "JSON-like" instead of true JSON makes them not very editor friendly. I do use them (especially app.tss) but for quick-and-dirty views where I don't even have a .js controller file, I don't want to create a .tss file just to set a property.
  8. Fokke Zandbergen 2016-03-01

    I've corrected the project to Alloy and changed the title to take it away from the font property (which brings up the best practice thing) and make it generic, where use cases like Map region paint a broader picture.
  9. Brenton House 2016-03-01

    [~fokkezb] How many levels deep were you thinking. I am assuming one but I wanted to make sure.
  10. Brenton House 2016-03-02

    I added new PR based on feedback: https://github.com/appcelerator/alloy/pull/765
  11. Fokke Zandbergen 2016-03-03

    I think one level would cover 95% of the use cases, but we could use [_.set](https://lodash.com/docs#set) to go beyond that. Could you include a test app? https://github.com/appcelerator/alloy/tree/master/tools If we implement this we'd also need a ticket for TISTUD to add XML autocompletion. I already checked it doesn't give any syntax errors.
  12. Brenton House 2016-03-03

    [~fokkezb] Does this mean you are replacing underscore with lodash? YES!!!!!!!!!!!!! :D
  13. Fokke Zandbergen 2016-03-03

    Uhm... no, but we should. Feel free to do a PR for ALOY-1168 AFAIK lodash is underscore compatible, so should be no problem to replace.
  14. Brenton House 2016-03-14

    Added test app: https://github.com/brentonhouse/brentonhouse.alloy/tree/feature-xml-attribute-prefix/test/apps/testing/ALOY-1363
  15. Malcolm Hollingsworth 2016-03-14

    [~brentonhouse] not liking that using style based properties directly in XML is a bad practice does not stop it being a bad practice. The suggestion that you should not have to create a tss for a single entry can only mean that sufficient consideration for the app structure has been performed. The distraction of this sort of ticket rather than focussing on fixing actual bugs that are plaguing the system is annoying. Your example of a font family or size could be solved with an entry in the app.tss to define an app wide style option (you could set more than one of course) then adding that class to the XML improves the app and tenders all these changes mute. More time to fix the bugs, less code to gain new bugs. The inclusion of style based properties in the creation of Alloy was regretted by its creator as it failed to provide true seperation. It was left in solely as a means for newbies and those transitioning from non-Alloy. I expect you may find those comments rude - that is not my intent. Should you wish to discuss it to get the other side of the coin (so to speak) feel free. You may gain new insights or stick to your own - I am happy with either outcome.
  16. Brenton House 2016-03-14

    [~core13] No offense taken! I completely realize that everyone has their own set of features that they really want. As a developer, my goal is to build awesome apps in the most simple way possible. Sometimes I do crazy things like defining an app in JSON and loading it into the app at runtime, so I don't always use TSS files. I just finally got around to adding some of these things as PR's instead of just complaining to myself... :) Most of my new desired features are now going into Adamantium (https://github.com/mobilehero/adamantium) so that I can get all the benefits of these new features without bothering the Appcelerator Dev teams. In the future, I will probably wait to see if any Adamantium features are desired by others in the community before creating a PR and Test Apps for Alloy. That's one of the many great advantages of open-source software!! Thanks for your feedback and I look forward to maybe implementing a feature you might want/need in the product!
  17. Brenton House 2016-03-17

    Not to completely derail a discussion that I started but... What if Alloy supported this instead: 
        <Map module="ti.map">
       <Annotations virtual="array">
          <Annotation id="appcHQ" myid="1" />
       </Annotations>
       <Region virtual="object" latitude="33.74511" longitude="-84.38993" latitudeDelta="0.01" longitudeDelta="0.01" />
    </Map>
    Where xml elements could be "virtual" in that they just set a property (of type object or array) on the parent object instead of creating a view. The property name would default to the element name (with lowercased first letter). This would allow you to go as you needed to and give you more flexibility. The other reason I am asking is to possibly reserve the attribute prefixes for platform specific properties. 
        <Alloy>
        <Label 
              ios:text="This is on iOS" 
              android:text="This is on Android" 
              mobileweb:text="This is on MobileWeb" 
              windows:text="This is on Windows" />
    </Alloy>
    Again, I know these kind of changes are not popular with everyone but I thought I would throw it out there. I am thick-skinned and can benefit from the discussions!
  18. Fokke Zandbergen 2016-03-18

    [~brentonhouse] I like both suggestions. The first I like because the less view-specific behavior Alloy needs to be aware off the better. However, I don't like adding too much protected attributes, maybe this would do? 
        <Map module="ti.map">
       <array:annotations>
          <Annotation id="appcHQ" myid="1" />
       </array:annotations>
       <object:region latitude="33.74511" longitude="-84.38993" latitudeDelta="0.01" longitudeDelta="0.01" />
    </Map>
    Would you think for a font that would mean doing the following instead of the earlier suggested font:fontSize attribute? Because that might conflict with platform specific attributes. 
        <Label text="hi">
      <object:font fontSize="10" />
    </Label>
    I've thought about your second example for tiapp.xml, where you would be able to set platform specific settings like app name, properties etc.
  19. Fokke Zandbergen 2016-03-18

    I think we better break this discussion in two: * Scalar (string/number/boolean) object property values: this ticket * Complex (array/object) object property/method values: ALOY-1371 The question now is, should we maybe not have a separate (more simple) way for scalar values and just require: 
        <Label text="hi">
      <object:font fontSize="10" />
    </Label>
  20. Malcolm Hollingsworth 2016-03-18

    Or just use the TSS files which are designed to perform this function for the Alloy MVC.
  21. Fokke Zandbergen 2016-03-18

    TSS files can't do ALOY-1371. But you do have an argument as too why we maybe should not resolve this ticket, but only ALOY-1371 which _would_ then allow developers still declare a font in XML that way, just not the more simple way suggested by this ticket.
  22. Malcolm Hollingsworth 2016-03-18

  23. Brenton House 2016-03-18

    [~core13] To continue with your metaphor... _What if you had a friend who was willing to give your car a new paint job for free while you were busy overhauling the "important" stuff. All you needed to do is make sure the paint job looked good and that paint didn't get on anything that wasn't supposed to be painted._ Would you really say no?
  24. Brenton House 2016-03-18

    [~fokkezb] What would be an example of the scalar properties that would be left after split? Are you talking about platform specific properties like ios:text or something else?
  25. Malcolm Hollingsworth 2016-03-18

    [~brentonhouse] I would welcome the offer provided the car was fixed first as otherwise the repaint will get in the way of the more important structural work. Once that was completed I would then have to see if the choice of colour is best for the car. Metaphor aside; I am not suggesting your work or idea does not have merit. But we are working inside a situation where there are significant long term problems that have not been started or have been abandoned. Where more recent additions to alloy get added that introduce new features requested for years rather than changing how something that already works is done. Most importantly, many things are being broken in each successive release that then have to be fixed in each subsequent release.
  26. Fokke Zandbergen 2016-03-18

    [~brentonhouse] Maybe _scalar_ wasn't the right term. I guess the original idea (<Label font:fontSize="14"> or even Label fontSize="14" are more like shorthands whereas ALOY-1371 is a full descriptive version. Since I agree with [~core13] that this original use case is preferred to be done via TSS and ALOY-1371 would still allow you do it in XML (just with a bit more code) if you need to (e.g. in data binding situations) I'd prefer ALOY-1371 over this ticket.
  27. Fokke Zandbergen 2016-03-18

    [~core13] creating tickets to discuss future features is not the same as scheduling them in, which I know [~ingo] and [~cng] do a great job at. But of course there's always time to merge a well-documented and tested PRs like those of [~brentonhouse] ;)
  28. Brenton House 2016-03-18

    [~core13] Maybe there is a better forum (slack?) where we could discuss this but I am curious which features you feel are critical and if we as a community can work together to do something to help?
  29. Brenton House 2016-03-18

    [~fokkezb] I tend to agree that ALOY-1371 would solve any problem that this ticket would solve, and more. The platform-specific property idea should probably be a new ticket. You can go ahead and close this ticket, if you agree.
  30. Fokke Zandbergen 2016-03-18

    Closed as _Won't Fix_ in favor of ALOY-1371
  31. Malcolm Hollingsworth 2016-03-18

    The [developer.appcelerator.com](https://developer.appcelerator.com/) being broken would be one of the first things to address. Then there are all the features that do not work, the properties that could be added but have not been to base views, the Alloy build issues that have started and stopped, broken and then fixed. You are correct this Jira is not the best place to discuss this, but a quick look at all the unresolved jiras would be.
  32. Fokke Zandbergen 2016-03-18

    Fixed, thanks [~core13]
  33. Lokesh Choudhary 2019-06-20

    Verified the fix with alloy 1.14.0-1. Resolving & closing. Studio Ver: 5.1.2.201903111843 SDK Ver: 8.0.2.GA OS Ver: 10.14.5 Xcode Ver: Xcode 10.2.1 Appc NPM: 4.2.13 Appc CLI: 7.1.0-master.22 Daemon Ver: 1.1.3 Ti CLI Ver: 5.2.1 Alloy Ver: 1.14.0-1 Node Ver: 8.15.1 NPM Ver: 6.4.1 Java Ver: 10.0.2 Devices: ⇨ google Pixel (Android 9) Simulator: Iphone XS 12.2

JSON Source