Thanks for your follow .

Assuming that I created attributes such as attr_Name, attr_Model, attr_Date, and so on with PythonCreator ,After the PythonCreator ,I want to expose these attributes, They are not imported from somewhere, so I can only manually enter each attribute name, if it can be specified as [attr*], it will be more convenient.

Ah, they are coming from the PythonCreator/PythonCaller. Maybe a better enhancement would be for us to enhance those to sense the names of attributes being created and expose them automatically?

Hi ​@lifalin2016 - thanks for the recent idea for requesting wildcards within the AttributeExposer.

To better understand the scenarios you have in mind, I have a couple of questions for you and other voters on this idea:

1. Where do the attribute names leading into the AttributeExposer usually come from? 
2. After these attributes are exposed, what is the next step in your workflow and how would wildcard support improve that?

Hi Andrea.

The data comes from reading multiple layers in FeatureReader from a WFS source. The layers are dynamically chosen, so data are output as generic.

After reading the data, I apply a BulkAttributeRenamer to add a prefix (e.g. wfs_), and I want to expose all attributes with set prefix (i.e. wfs_*).

Now I think about it, maybe an option to expose renamed attributes in the BulkAttributeRenamer might be a better option ?

Cheers.

FME can not Expose attributes dynamic. If you think about it, it makes sense.

The workbench can not know what the resulting attributes are when it does not know what data it gets.

With featurecaching it could know what attributes the current run has, and you can select those attributes to be exposed. But the next run might not have those attributes, and might have more.

If you know what attributes will be the result of your process than merging the attributes or bulkattributerenamer could help.